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Technology  Transition  Push: 

A  Case  Study  of  Rate  MonotonIc  Analysis  (Part  1) 


Abstract:  This  case  study  reports  on  efforts  to  transform  rate  monotonic 
scheduling  theory  from  an  academic  theory  into  a  practical  analytical  technique 
and  to  transition  that  technique  into  routine  practice  among  developers  and 
maintainers  of  software  emb^ded  in  reai-time  systems. 


1  Introduction 

Rate  monotonic  analysis  (RMA)  is  a  simple,  practical,  mathematically  sound  way  to  guarantee 
that  all  timing  requirements  will  be  met  in  real-time  systems.  RMA  allows  engineers  to  under¬ 
stand  and  predict  the  timing  behavior  of  real-time  software  to  a  degree  not  previously  possible. 
The  Rate  Monotonic  Analysis  for  Real-Time  Systems  (RMARTS)  Project  at  the  Software  En¬ 
gineering  Institute  (SEI)  has  demonstrated  how  to  design,  implement,  troubleshoot,  and  main¬ 
tain  real-time  systems  using  RMA.  From  1987-1992.  the  project  worked  to  develop  the 
technology  and  encourage  its  widespread  use  to  reduce  risk  in  building  real-time  systems. 

The  acquisition  and  introduction  of  new  software  technologies  (including  tools,  methods,  and 
management  approaches)  is  so  much  a  part  of  most  software  development  and  maintenance 
efforts  that  we  do  not  even  call  it  out  as  a  separate  activity.  However,  one  reasonable  expla¬ 
nation  for  why  cost  and  schedule  overruns  are  so  common  in  software  projects  is  the  continual 
learning  required  on  the  part  of  software  engineers  and  managers.  One  solution  to  the  soft¬ 
ware  “crisis”  is  to  better  understand  and  anticipate  problems  and  barriers  in  the  introduction  of 
new  software  technologies.  (This  is  the  focus  of  ttie  Transition  Models  Project.'') 

This  case  study  describes  efforts  of  the  RMARTS  Project  to  transform  rate  monotonic  sched¬ 
uling  theory  from  an  academic  theory  into  rate  monotonic  analysis— a  practical  technique  for 
analyzing  existing  systems  and  designing  new  ones.  Of  particular  importance  is  how  the 
RMARTS  Project  transitioned  this  technology  to  the  community  of  potential  users.  This  docu¬ 
ment  is  Part  1  of  the  study.  It  examines  how  problems  of  introduction,  learning,  and  use  were 
anticipated  and  addressed  during  the  development  of  the  technology.  Part  2  (CMU/SEI-93- 
TR-30)  describes  the  experiences  of  several  projects  in  one  organization  in  attempting  to 
adopt  and  apply  RMA. 

The  investigation  of  RMA  transition  activities  is  intended  to  make  a  twofold  contribution  to 
greater  understanding  of  technology  transition.^  Our  aim  is  to  encourage  researchers  to 


'-The  study  of  the  maturation  of  RMA  is  one  part  of  a  larger  effort  to  build  a  Ihick  description*  [Geertz  1972]  of 
software  technology  transition.  (Such  an  ethnographic  description  makes  the  tacit  explicit;  attends  to  cuftural 
practice,  including  communication  in  a  given  community,  organization,  or  group;  attends  to  detail  and  not  only 
abstract  concepts;  and  captures  language  as  it  is  in  use — as  it  reveals  the  values  and  priorities  of  those  groups.) 
Additiortal  work  in  the  Transition  Models  Project  explores  related  levels  of  analysis;  for  example,  Fowler  &  Levine 
[1 993]  offer  a  conceptual  framework  for  technology  transition,  from  the  birth  of  a  technology  to  its  retirement. 
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further  explore  the  precepts  presented  here  with  respect  to  other  software  technologies  and 
to  help  practitioners  learn  from  and  apply  strategies  used  by  the  RMARTS  team.  Practically 
speaking,  people  working  in  the  area  of  technology  transition  shoukt  be  able  to  adapt  the  heu¬ 
ristics  identified  here  with  respect  to  another  software  technology.  The  case  study  approach 
is  a  good  match  for  our  double  purpose:  the  research  method  allows  for  close  examination  and 
interpretation;  and.  the  detailed  case  study  form  can  provide  practitioners  with  surrogate  ex¬ 
perience  of  a  complex  transition  situation. 

As  indicated,  the  case  study  consists  of  two  technical  reports:  Part  1  (this  document)  is  con¬ 
cerned  with  the  analysis  of  the  transition  activities  according  to  phases  of  a  technology  matu¬ 
ration  life  cycle;  and  Part  2  investigates  the  processes  of  adoption  and  implementation. 
Together,  the  two  parts  allow  us  to  attend  to  develo^ent  and  user  perspectives— or  more  col¬ 
loquially  put,  to  technology  push  and  technology  pull.  Part  1  of  the  case  study  includes  these 
sections:  a  brief  description  of  RMA;  the  rationale  for  selecting  it  as  a  topic  of  study;  descrip¬ 
tions  of  several  technology  maturation  models;  research  method  and  procedure;  results;  and 
implications  and  directions  for  future  research. 

The  data  used  for  Part  1  of  the  study  are  largely  drawn  from  the  reports  of  RMARTS  Project 
accomplishments  in  the  annual  SEI  one  and  five  year  plans.  Transition  activities  from  1987 
through  the  first  half  of  1993  were  analyzed  and  coded  according  to  phases  of  a  technology 
maturation  life  cycle.  The  coded  data  were  then  (x>rroborated  by  supporting  artifacts  and  by 
RMARTS  Project  members’  reviews  of  the  analysis.  Additional  Information  was  collected 
through  financial  records,  attendance  at  project  meetings,  and  interviews.  A  more  detailed  de¬ 
scription  follows  In  the  Method  section  of  this  report  (Section  5,  page  15). 


The  phrase  “technology  transfer”  is  usually  preferred,  except  within  the  DoD.  For  the  purposes  of  this  report,  we 
consider  “technology  transfer,”  “technology  transition,”  and  “technology  deployment' to  be  synonymous.  In  addi¬ 
tion,  we  agree  with  Tornatzky  &  Fleischer  [1990]:  “Technology  transfer,  while  a  commonly  used  term,  has  a  host 
of  nuances,  not  the  least  of  which  is  the  image  that  technology  is  something  that  is  physical,  comes  in  large  crates 
or  on  pallets,  and  gets  literally  moved  from  place  to  place.”  On  this  basis,  they  “use  the  more  inclusive  and  less 
encumbered  notion  of  d^loymsnt  (p.  118;  italics  Tornatzky  a  Fleischer)”;  we  prefer  “technology  transition.’ 
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2  Rate  Monotonic  Analysis 


RMA  helps  software  engineers  who  are  designing,  building,  troubleshooting,  and  n^aintaining 
real-time  systems  to  understand  and  predict  the  timing  behavior  of  hard  real-time  systems  to 
a  degree  not  previously  possible.  Real-time  systems  are  often  seen  as  a  “niche"  within  the 
software  world,  but  they  are  a  critical  niche.  Real-time  software  is  often  embedded  in  life- 
critical  systems  such  as  avionics  and  other  transportation  systems,  patient  monitoring  equip¬ 
ment,  and  process  control  systems  in  chemical  processing  and  nuclear  power  plants. 

In  the  software  embedded  in  such  real-time  systems,  multiple  tasks  contend  for  the  use  of  a 
finite  amount  of  resource— for  example,  of  the  central  processing  unit  (CPU).  Typically  these 
tasks,  such  as  monitoring  altitude,  monitoring  cabin  pressure,  or  controlling  fuel  injection  level 
on  an  aircraft,  are  of  differing  priorities  and  require  different  amounts  of  CPU  effort  to  complete 
their  work.  These  tasks  can  occur  both  at  regular  intervals  and  irregularly.  Real-time  systems 
must  complete  critical  tasks  (for  example,  the  lowering  of  the  landing  gear)  by  particular  dead¬ 
lines,  or  place  the  entire  system  at  risk.  Without  the  appropriate  handling  of  schedules  and  pri¬ 
orities,  a  lower  priority  task  of  relatively  long  duration — ^for  example,  intermittent  monitoring  of 
passenger  cabin  pressure —  can  monopolize  the  CPU  at  the  expense  of  a  critical  task. 

Traditionally,  the  approach  to  calculating  appropriate  task  mixes  has  been  by  trial  and  error. 
Programs  are  written  to  accomplish  the  required  tasks,  but  until  the  tasks  are  integrated  into 
a  system  and  tested  as  a  system,  there  is  no  way  to  know  whether  all  tasks  can  be  accom¬ 
plished  within  the  constraints  of  the  available  CPU.  Most  often  deadlines  are  not  met  until  after 
many  iterations  of  testing,  program  revision,  and  more  testing.  For  these  reasons,  real-time 
systems  have  earned  the  reputation  of  being  expensive,  behind  schedule,  risky,  and  difficult 
to  maintain. 

While  the  traditional  approach  is  manageable  for  simple  systems,  especially  when  particular 
system  designers  have  become  expert  in  the  successful  design  of  task  mixes,  it  is  unmanage¬ 
able  for  large  systems.  As  large  real-time  systems  are  increasingly  built  from  commercial  “off- 
the-shelf”  or  separately  contracted  subsystems,  handcrafting  of  scheduling  is  increasingly 
risky.  Rate  monotonic  scheduling  theory  and  its  method  of  application,  RMA.  provide  a  scien¬ 
tific  approach  that  can  be  used,  before  system  integration,  to  determine  whether  schedule  re¬ 
quirements  can  be  met  and  how  well,  and  under  what  conditions  task  completion  can  be 
guaranteed.^  Because  RMA  solves  a  difficult  problem  early  in  the  development  of  a  real-time 
system,  it  is  an  important  innovation  with  respect  to  technical  work  and  its  management— it 
can  result  in  significant  savings  not  only  of  CPU  but  potentially  of  both  system  development 
resources  and  operational  resources  such  as  hardware. 


The  early  focus  of  RMA  ensured  that  as  long  as  CPU  resource  utilization  lies  below  a  certain  bound  (generally  a 
percentage  of  total  possible  resource),  all  the  timing  requirements  will  be  met  [Sha  &  Goodenough  1990).  More 
recently,  the  focus  of  RMA  has  shifted  to  computing  the  worst-case  response  time  and  comparing  it  to  the  re¬ 
sponse  time  requirement. 
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3  Rationale  and  Background 


The  transformation  of  rate  monotonic  scheduling  theory  into  RMA  and  its  reduction  to  practice 
did  not  happen  by  accident.  The  original  Carnegie  Mellon  University  (CMU)  te2im  (the  Ad¬ 
vanced  Real-Time  Technology  Project)  and  the  subsequent  alliance  of  SEI  and  CMU  teams 
have  focused  on  the  key  problems  that  emerged  from  the  development  of  national  projects.  In 
fact,  the  selection  of  the  theoretical  foundation  for  real-time  system  development  as  an  area 
of  study  originated  with  the  need  to  solve  (M’oblems  with  the  development  of  the  Navy  BSY-1 
system.^ 

The  Software  Engineering  Institute,  a  federsdiy  funded  research  and  development  center 
(FFRDC)  at  CMU,  is  well  positioned  to  explore  interactions  between  theory  and  practice.  Its 
engineering  focus  seeks  a  balance  between  ease  of  implementation  (typically  the  concern  of 
practice)  and  analyzability  (a  key  theoretical  issue).  Such  interaction  between  theory  and  prac¬ 
tice  is  necessarily  iterative.  When  theory  is  focused  on  actual  problems  encountered  in  devel¬ 
opment,  the  problem  is  well  set  and  well  defined;  work  can  then  be  done,  iteratively,  to  test 
and  refine  the  theory. 

Withiii  the  SEI  and  its  constituencies,  the  development  of  RMA  and  the  work  of  the  RMARTS 
Project  is  considered  an  exemplary  model  of  the  interaction  between  theory  and  practice.  Sat¬ 
isfaction  of  three  additional  criteria  also  influenced  our  decision  to  study  RMA: 

1 .  The  characteristics  of  the  technology  itself— including  its  size,  observability, 
and  maturity. 

2.  The  qualities  and  qualifications  of  the  change  agents  involved. 

3.  The  accessibility  of  the  history  of  the  technology. 

We  discuss  each  of  these  in  turn. 

3.1  Characteristics  of  the  Technology:  Size,  Observabiiity,  and 
Maturity 

studying  the  transition  of  software  technologies  is  difficult  for  a  number  of  reasons.  First,  the 
process-intensive  nature  of  software  technologies  means  complex  interaction  between  the  so¬ 
cial  context  and  the  technical  content  of  the  technology  [Tomatzky  &  Fleischer  1 990].The  chal¬ 
lenge  of  studying  transition  in  an  organizational  setting  is  well  documented  [Nord  &  Tucker 
1987,  Yin  1984].  Second,  the  adoption  of  many  software  technologies  occurs  over  an  extend¬ 
ed  time  period,  at  least  months  and  often  years.  Third,  technology  introduction  has  an  impact 
on  not  only  the  technical  subsystem,  but  the  managerial,  strategic,  human,  and  culturai  sub¬ 
systems  as  well  [Morgan  1 986]. 


*■  The  paper,  "Rate  Monotonic  Analysis  for  Real-Time  Systems’  by  Sha,  Klein  &  Goodenoogh  [1991],  reviewed 
some  important  historical  decisions  in  the  development  of  RMA. 
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RMA  requirements  for  effective  application  are  relatively  limited.  For  example,  while  RMA 
does  require  engineers  to  reframe  their  understanding  of  scheduling  issues  to  a  more  abstract 
level,  only  moderate  training  is  required  for  people  to  be  effective  in  using  the  technology.^  It 
can  be  adopted  by  an  individual  engineer  as  part  of  his  or  her  approach  to  designing  or  ana¬ 
lyzing  systems;  it  can  also  be  applied  at  almost  any  point  in  time  in  system  development  or 
maintenance.  RMARTS  Project  members  recount  how  they  are  able  to  quickly  demonstrate, 
in  consulting  and  classroom  settings,  the  utility  of  the  approach. 

According  to  Adler  &  Shenhar  [1990],  adopting  a  technology  that  will  change  skills  and  proce¬ 
dures  can  be  accomplished  typically  within  the  space  of  weeks;  in  contrast,  adopting  a  tech¬ 
nology  involving  a  change  in  either  structure  or  strategy  requires  months  of  planning  and 
implementation.  RMA  can  be  incorporated  into  software  engineering  processes  with  relative 
ease  over  a  period  of  several  months.  In  this  regard,  we  classify  the  technology  as  “small.’^ 
The  initial  stages  of  user  commitment  to  the  use  of  RMA — contact,  awarene~,s,  understanding, 
and  trial  use  [Conner  &  Patterson  1982] — can  be  observed  within  a  short  time.  To  use  RMA, 
neither  managers  nor  engineers  must  adjust  their  paradigm  of  software  development  signifi¬ 
cantly. 

These  same  factors  make  RMARTS  transition  readily  “observable”  [Roge  rs  1983]  within  a  rea¬ 
sonable  period  of  time.  RMA  can  be  adopted  incrementally:  its  adoption  can  range  from  appli¬ 
cation  to  an  existing  system  by  one  engineer  to  application  across  an  entire  division  as 
standard  practice  in  designing  new  systems.  A  project  team  or  group  of  project  engineers  can 
adopt  and  implement  RMA  within  a  few  months.  This  means  transition  can  be  studied  not  only 
retrospectively  but  “in  process,”^  and  that  process  is  relatively  short-term.  In  addition,  because 
RMA  is  a  technology  without  extensive  “cultural”  content  (in  contrast  with  a  technology  such 
as  Total  Quality  Management),  its  transition  process  would  be  less  muddied  by  major  shifts  in 
attitude  and  belief  systems.® 

Finally,  the  maturity  of  RMA  is  important.  Given  the  process-intensive  nature  of  software  tech¬ 
nologies  [Tomatzky  &  Fleischer  1990],  less  mature  technologies  are  likely  to  have  poorly  de- 


One  project  member  and  former  resident  affiliate  stated  in  an  interview  that  over  a  period  of  time,  his  use  of  RMA 
had  caused  a  shift  in  his  view  of  archKectures.  He  began  to  see  an  important  distinction  between  ‘architectures* 
and  ‘attributes  of  architectures.*  He  noted  that  he  began  to  look  at  ‘software  performance  in  terms  of  preemption, 
computation,  and  blocking.*  (These  are  concepts  used  in  RMA  theory.) 

Compare  this  type  of  technology  with,  for  example,  a  CASE  tool  that  may  require  adjustment  to  interfaces  with 
other  software,  upgraded  or  new  hardware,  and  revised  documentation  standards.  In  this  respect,  we  classify 
RMA  as  ‘small.*  For  a  preliminary  taxonomy  of  software  technology  types,  see  Fowler  &  Levine  [1 992a].  We  em¬ 
phasize  that  the  type  of  a  technology  (and  its  related  size)  represents  only  one  dimension  of  a  technology's  pro¬ 
file.  The  maturity  of  the  technology  and  its  ease  of  implementation — in  other  words,  the  degree  to  which  it  is  a 
“whole  product’  [Moore  1991]  are  also  critical  dimensions  to  the  technology’s  complete  profile. 

Studying  the  in-process  adoption  of  RMA  is  not  the  subject  of  this  report;  however,  future  investigations  may  lead 
in  this  direction. 

Any  technology  has  some  cultural  content,  in  the  sense  of  requiring  an  adjustment  in  the  user’s  belief  systems 
and  behavior.  For  example,  RMA  requires  acceptance  of  logical  concurrency,  a  shift  for  most  software  ertgineers 
and  their  managers,  with  some  implications,  albeit  limited,  for  the  structure  and  scheduling  of  their  work.  It  does 
not,  apparently,  require  restructuring  of  the  software  project  management  process  or  of  reward  systems.  See  Part 
2  of  this  case  study  for  more  information. 
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fined  transition  processes.  The  iimited  impact  of  RMA  on  the  structure  and  work  processes  of 
the  organization  makes  it  somewhat  easier  to  separate  technical  problems  from  problems  in 
the  transition  approach.  In  fact,  while  RMA  is  not  yet  fully  mature  in  the  sense  of  a  commercial 
whole  product  [Moore  1991]  that  incorporates  the  secondary  products  and  services  that  late 
majority  adopters  need  (such  as  training  and  support,  courses,  documentation,  handbooks, 
etc.),  as  an  analytical  method  RMA  is  no  longer  evolving  rapidly.^ 

3.2  Change  Agent  Qualities  and  Qualifications 

Studying  less  as  well  as  more  successful  cases  is  productive;  however,  we  begin  with  a  tech¬ 
nology  transition  effort  that  was  considered  a  success.  This  was  so  with  RMA  within  the  SEI 
and  its  larger  context;  and  part  of  its  success  has  been  attributed  to  the  qualifications  of  the 
change  agents  associated  with  the  technology.  The  RMARTS  Project  was  well  endowed  with 
senior  personnel  who,  while  not  trained  as  change  agents,  were  highly  credible  with  their 
peers  and  well-schooled  in  the  politics  of  professional  and  industry  associations.  Collectively, 
their  capabilities  beyond  software  engineering  and  computer  science  included  project  man¬ 
agement,  consulting,  acquisition,  and  research.  We  elaborate  on  some  of  these  capabilities  to 
illustrate  how  change  agent  qualifications  impacted  transition. 

In  terms  of  basics,  several  members  of  the  project  were  exposed  to  ideas  about  transition  early 
in  the  life  of  RMARTS.  This  exposure  included:  awareness  of  case  studies  of  software  tech¬ 
nology  transition  [Redwine  et  al  1984];  an  understanding  of  the  nature  of  resistance  to  tech¬ 
nological  change  from  material  In  the  Managing  Technological  Change  Workshop,  taught  at 
the  SEI  since  1988;  and  discussion  of  technology  advocates  and  receptor  functions^^. 

The  RMARTS  staffing  turnover  was  minimal  during  the  five  years  of  the  project’s  official  exist¬ 
ence  (1988  -  1992),^^  since  turnover  was  mainly  limited  to  resident  affiliates  (personnel  on 
temporary  assignment  from  industry  or  government  organizations).  John  Goodenough  and  Lui 
Sha,  cofounders  of  RMARTS,  both  had  a  strong  interest  in  the  subject  of  technology  transition. 
Their  plan  for  transitioning  RMA  technology  was  not  detailed  or  formal,  but  consisted  of  innu¬ 
merable  course  corrections  toward  a  vision  of  the  world  post-institutionalization  of  RMA.  in 
1991 ,  roughly  halfway  through  the  life  of  the  project,  RMARTS  developed  a  "stage  model  of 
technology  transition”  to  explain  and  describe  what  the  project  had  done  and  was  planning  to 
do.^^  In  the  following  section.  Technology  Life  Cycle  Models,  we  describe  this  model  in  great¬ 
er  detail.  We  also  discuss  other  models  that  are  consistent  with  the  research  and  development 
(R  &  D)  life  cycle. 

Goodenough  was  cognizant  of  application  domains  within  the  world  of  real-time  systems  that 
would  have  use  for  RMA.  Sha  recruited  resident  affiliates  from  key  domains.  His  purpose  was 


^  There  are  efforts  underway  to  encapsulate  and  guide  the  use  of  the  RMA  method  with  software  tools. 

These  concepts  were  documented  [Fowler  1990],  and  were  commonly  presented  to  new  SEI  resident  affiliates 
as  part  of  their  orientation  as  early  as  the  winter  of  1988.  (Personal  communication,  Tom  Ralya,  October  1991.) 
Activities  took  place  before  1988  and  after  1992;  however,  the  project  was  an  approved  SEI  project  during  the 
dates  cited. 
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twofold:  to  provide  persons  who  could  carry  the  technology  back  to  their  home  organization, 
and  who  would  regularly  provide  a  skeptical,  real-world  view  of  limitations  of  the  technology 
that  m^ht  prevent  its  application  and  acceptance.  In  particular,  the  affiliates  helped  identify 
technical  barriers  to  adoption,  thereby  keeping  RMARTS  attuned  to  transition  issues.^  ^  For 
example,  one  resident  affiliate  was  not  convince  that  the  Ada  programming  language  could 
work  for  real-time  systems,  and  he  often  played  devil's  advocate. 

A  critical  aspect  of  the  transition  strategy  was  convincing  industry  standards  committees  to 
support,  or  at  least  not  preclude,  the  use  of  RMA  technology  in  applications.  Staff  selected  for 
the  RMARTS  Project  included  several  individuals  with  experience  in  real-time  systems  who 
had  been  active  in.  or  had  credibility  with,  industry  standards  groups.  These  individuals  be¬ 
came  members  of  the  standards  groups,  and  influenced  the  direction  of  key  standards,  such 
as  the  IEEE  FutureBus-t-.  Without  the  standards  work,  RMA  could  have  been  adopted  and  ap¬ 
plied  by  individual  engineers;  with  standards,  broad  use  of  RMA  within  real-time  systems  is 
becoming  a  real  possibility. 

3.3  History 

Extensive  and  largely  nonproprietary  documentation  on  RMA  was  available,  both  formal  and 
informal,  from  which  case  study  material  could  be  drawn.'*  ^  We  have  already  mentioned  the 
availability  of  project  members  whose  tenure  with  the  project  was  long.  In  addition.  Carnegie 
Mellon  University  faculty  who  evolved  the  original  [Liu  &  Layland  1973]  rate  monotonic  sched¬ 
uling  theory  from  which  RMA  was  derived  remain  at  the  university.  Former  resident  affiliates 
and  personnel  from  organizations  that  cooperated  with  RMARTS  to  test  RMA  were  also  avail¬ 
able  for  interview. 

In  sum.  the  selection  of  RMA  as  a  transition  case  study  was  based  on  the  characteristics  of 
the  technology— its  size,  observability,  and  mahjrity— the  qualities  and  qualifications  of  the 
change  agents  involved,  and  the  availability  of  individuals  and  documents  that  helped  us  trace 
the  development  of  the  emerging  technology. 


The  RMARTS'  model  consists  of  five  stages:  promising  technology  selected,  key  limitations  addressed,  value 
and  transitionability  demonstrated,  self-sustaining  transition,  and  widespread  use.  More  recently.  Goodenough 
has  expressed  a  preference  for  changing  the  name  of  stage  two  (originally,  key  limitations  address^)  to;  t>arriers 
to  ado^ion  removed.  While  Irey  [imitations*  often  constitute  bakers  to  adoption,  he  notes  this  desenres  more 
emphasis  early  on:  'key  limftations  addressed'  sounds  I9(e  academic  polishing  rather  than  what  we  (RMARTS) 
attempted  to  do.*  (Personal  correspondence  with  John  Goodenough,  October  1 993.)  For  the  purpose  d  this  case 
study,  we  use  the  RMARTS  model;  however,  we  note  thsd  their  representation  resembles  that  of  others 
[Botkin  &  Matthews  1992,  Redwine  et  al  1984,  Tornatzky  &  Fleischer  1990]. 

Resident  affiliates  were  also  recruited  from  universities  to  begin  to  develop  a  cadre  of  researchers  who  would 
extend  RMA  and  related  theory. 

Format  deliverables  include:  reports  required  of  the  SEI  by  contract,  technical  reports,  and  external  publications; 
informal  documentation  includes  electronic  mail,  meeting  minutes,  and  presentation  material. 
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4  Technology  Life  Cycle  Models 


Models  of  R  &  D  represent  only  one  part  of  the  life  of  a  technology.  In  this  section,  we  discuss 
the  technology  life  cycle  (Figure  4*1 );  a  more  specific  R  &  D  life  cycle;  and.  finally,  we  describe 
the  RMARTS  Project  stage  model— a  model  that  synthesizes  issues  of  technology  develop¬ 
ment  with  issues  of  technology  transition,  in  other  words,  we  begin  with  the  larger  context  of 
technology  transition,  narrow  the  focus  to  R  &  D  activity,  and  then  consider  the  RMARTS 
Project's  specific  model.  The  latter  is  our  primary  concern. _ 
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Figure  4-1:  Technology  Life  Cycle 


In  the  course  of  investigating  technology  transition  as  understood  by  disciplines  such  as  man¬ 
agement  science,  political  science,  communication,  and  economics,  we  have  discovered  three 
major  perspectives  or  life  cycles.  These  are:  R  &  0  (including  the  creation  of  prototypes),  new 
product  development,  and  technology  adoption  and  implementation.  Technology  transition  oc¬ 
curs  throughout  technology  development  from  the  birth  of  a  technology  until  its  retirement.  For 
example,  technology  that  has  been  commercially  developed  and  is  in  use  in  an  organization 
has  most  likely  been  transitioned  at  least  twice,  between  communities  respectively  concerned 
with  R  &  D,  new  product  development,  and  adoption  and  implementation.  In  addition,  the  tech¬ 
nology  is  transitioned  as  it  progresses  through  its  life  cycle  within  each  community  [Fowler  & 
Levine  1993].  Traditionally,  these  communities  have  only  limited  interaction  with  each  other. 

R  &  D,  then,  represents  only  one  part  of  the  larger  technology  life  cycle:  the  focus  of  R  &  D  is 
predominantly  on  the  changes  that  the  technology  itself  goes  through  as  it  matures  [Botkin  & 
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Matthews  19d2.  Moore  1991,  Tomatzky  &  Fleteher  1990].  Redwine’s  representation  [1984] 
of  the  R  &  D  life  cyde  is  typical.^^  The  Nfe  cyde  indudes 

•  Concept  formulation 

•  Development  and  extension 

•  Enhancement  and  exploration  (internal) 

•  Enhancement  and  exploration  (external) 

•  (Early)  popularization.^® 

The  emphasis  here  is  primarily  on  technology  Ipush.”  and  the  perspective  is  that  of  ttte  re¬ 
searcher  or  developer.  From  this  perspective,  trarrsition  means  orchestrating  the  development 
of  the  technology  by  ‘tnoving”  it  systematicaUy  ttwough  stages  of  development  until  it  is  finaHy 
incorporated  into  a  prototype  product''^ 

During  ttie  development  of  RMA,  the  RMARTS  Pro|ect  looked  to  R  &  D  models  for  guideiines 
or  heuristics  for  accomplishing  successful  transition.  During  interviews  with  RMARTS  Project 
members  (in  1992),  they  reflected  on  their  earfler  considerations  (through  1990-1991)  of  the 
life  cyde  described  above  [Redwine  et  al  1984].  RMARTS  staff  had  seen  the  model  to  be  gen¬ 
erally  relevant  but  of  limited  use  for  their  purposes.  Further,  they  noted  that  some  phases 
seemed  to  blur— for  example,  the  two  phases  concerning  enhancement  and  exploration.  Oth¬ 
er  phases,  they  remarked,  «vere  difficult  to  operationalize— how  did  you  actually  achieve  pop¬ 
ularization?  in  1990-91.  RMARTS  was  trying  to  find  a  way  to  characterize  its  own  activities. 
These  activitim  could  then  be  understood  at  the  Software  Engineering  Institute,  and  potential¬ 
ly  they  could  provide  a  model  for  others  to  follow.  The  RMARTS  Project  preference  was  for  an 
active  model,  one  that  would  identify  classes  of  activity  to  be  performed,  and  related  aspects 
of  motivation.  Such  a  model  would  help  throughout  development  and  transition  to  answer  the 
question:  what  do  you  do  in  order  to  push  and  in  order  to  facilitate  pull? 


The  following  is  anothsr  sxampls.  In  woifcing  on  an  mtV  vsnton  of  this  study,  during  FaH  1991 ,  w*  axchangad 
informai  correspondance  with  Nail  Eastman  (of  IBM),  a  mambar  of  tha  SEI  Board  of  Visitors.  At  that  tima,  East¬ 
man  rafarrad  to  fiva  stagas:  rasaarch  activity,  tachnology  salaction,  tachnology  anginaaring.  tachnology  amploy- 
mant,  and  practica. 

Convarrtionally.  tha  R  &  D  Nfa  cyda  includas  "aarly  popularization’  [Radwina  at  al  1984].  Howavar,  givan  what 
wa  now  know  about  tachnology  transition  and  tha  thraa  intartocking  lifa  cydas,  wa  would  aigua  that  aarty  popu¬ 
larization  occurs  as  a  part  of  naw  product  davalopmant. 

A  good  axampla  of  this  is  tha  U.S  Dapartmant  of  Dafansa  funding  procass  with  dWarant  typas  of  funding  for 
diffarant  stagas  of  tachnology  maturatkm.  Rasaarch  activity  movas  through  tha  foflowing:  basic  (univarsity)  ra¬ 
saarch,  exploratory  rasaardt,  appiiad  rasaarch.  appliad  rasaarch  assodatad  with  a  spa^  program,  daw^ 
mental  rasaarch,  ate. 
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Continued  disoutsion  led  the  RMARTS  Prefect  to  develop  its  own  nKXtel  in  1991.  The 
RMARTS  transition  model  consisted  of  five  stapes: 

•  Stage  1 :  Promising  technology  sele^ed 

•  stage  2:  Key  limitations  addressed 

•  stage  3:  Value  and  transitionabiiity  demonstrated 

•  Stage  4:  Self-sustaining  transition 

•  Stage  5:  Widespread  use  in  target  population 

For  the  SEI,  an  FFROC,  constrained  by  law  to  250  members  of  the  technical  staff,  the  issue 
of  achieving  widespread  use  or  popularization  (of  muK^  technologies,  not  only  RMA)  r^xe- 
sents  a  significant  challenge.  The  Institute's  mission,  to  advance  the  state  of  the  softw^  en¬ 
gineering  practice,  requires  a  special  set  of  technology  transition  strategies.  The  most 
controversial  ideas  to  surface,  then,  with  respect  to  the  RMARTS  model,  concerned  Iransi- 
tionability”  and  the  necessary  mechanisms  to  harness  natural  phenomena  (as  depicted  in  con¬ 
ventional  R  &  D  models).  RMARTS  Project  n^bers  stated  that  they  felt  they  achieved  a 
breakthrough  with  the  notion  of  “leveraging  the  infrastructure"  and  the  related  idea  of  “self-sus¬ 
taining  transition.”  Essentially,  self-sustaining  transition  involved  developing  a  community  of 
partners  who  would  help  create  and  service  the  market  for  RMA. 

Briefly  summarized,  the  RMARTS  transition  model  for  RMA  is  as  follows''^:  Stage  1,  prom^ng 
te^nology  selected,  involves  working  with  a  customer  to  find  a  technology  that  solves  a  real 
problem.  In  1982,  IBM  came  to  CMU  with  a  problem  that  led  to  the  exploitation  of  rate  mono¬ 
tonic  scheduling  theory.  During  Stage  2.  key  limitaOons  addressed,  RMARTS  worked  with  us¬ 
ers  to  ensure  that  real  problems  were  being  solved  and  worked  with  theoreticians  to  tind 
technical  solutions.  Identifying  and  removing  barriers  was  critical  here.  In  adefition,  the  project 
developed  tutorial  materials  as  trial  transition  vehicles.  RMARTS  vvorked  on  their  own  and  with 
IBM  at  this  stage  starting  in  late  1987.  Stage  3,  demonstrate  value  and  transItionaiMity,  in¬ 
volves  demonstrating  value  by  solving  or  discovering  problems.  The  project  developed  suc¬ 
cess  stories  (working  with  IBM  and  NASA)  and  did  pilot  transition  to  develop  and  demonstrate 
the  successful  approach.^^  These  efforts  started  in  late  1989.  In  Stage  4,  self-sustadrthg  tran¬ 
sition,  RMARTS  began  to  develop  the  market  for  RMA.  This  is  the  stage  that  RMA  is  presently 
at.^  Self-sustaining  transition  for  RMA  means  that  others  are  teaching  RMA;  others  are  pro¬ 
viding  consulting  services;  compiler  vendors  support  rate  monotonic  algorithms;  hardware 
support  encourages  use  of  RMA;  procurement  organizations  see  RMA  as  a  plus;  and  national 


Th«  summary  dMcription  thW  follows  draws  heavHy  fioffl  •  praMfitation  on  Rato  Monaionic  ArwiyciS  for  RmI- 
Tima  Systams  by  John  Goodanough.  Tha  prasantation  was  an  information  saminar  at  tha  Sollwata  Enginaaring 
Instituta.  March  1991. 

A  pramisa  at  work  hara  was:  a  solution  to  a  problam  is  usalass  if  you  cant  gat  paopla  to  adopt  it  Tha  prpjact 
fbcusad  on  rafining  adoption  stratagias  and  dwabping  transition  support  malarial 
WhHa  tha  RMARTS  Prpjact  officially  dosad  down  at  tha  and  of  1992,  Ray  Obanza,  mambarof  tha  Products  and 
Sarvicas  Planning  function,  has  taken  tha  laad  on  efforts  ralaling  to  saff-sustaining  transitfon.  Tha  first  RMA  Us¬ 
ers’  Forum  was  held  in  Saptember  1992;  tha  second  forum  was  haU  in  Novambar  1993.  In  tha  summer  of  1993, 
Khjwar  Academic  Publishars  released  A  Pmaitionf$  Handbook  hrRaat-TImaAnalyaiabr  KWn,  Ra^  PoMk, 
Obanza,  and  Gonzilaz  Harbour.  Several  tool  buildars  are  planning  to  develop  tools  for  RMA. 
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standards  allow  and  encourage  the  use  of  RMA.  Stage  5,  widespread  use,  where  the  technol¬ 
ogy  is  routinely  used  by  a  significant  portion  of  the  targeted  end-user  pr^uiation.  remains 
ahead.  For  RMA,  the  targeted  group  includes:  real-time  system  designers  and  developers,  de¬ 
velopers  of  runtime  systems,  teachers  and  developers  of  academic  courses  on  real-time  the¬ 
ory,  those  performing  academic  research  leading  to  improved  theory;  and  those  performing 
engineering  improvements  outside  of  the  SEI.  These  targets  (or  measures  of  success)  were 
identified  during  the  planning  stages  of  the  project,  not  post  hoc. 

Three  critical  issues  must  be  noted  with  respect  to  the  RMARTS  transition  model.  First,  the 
model  compresses  the  larger  technology  life  cycle  model  based  on  the  three  interlocking  life 
cycles  of  R  &  D,  new  product  development,  and  adoption  and  implementation.  Second,  the 
model  accomplishes  this  compression  by  relying  on  and  leveraging  an  existing  infrastructure. 
For  example,  instead  of  building  a  product  itself,  the  SEI  secures  a  partnership  with  a  new 
product  developer,  such  as  a  vendor  or  tool  builder,  and  hands  off  technical  materials  to  en¬ 
able  product  development^^  Finally,  the  RMARTS  Project’s  awareness  of  the  need  to  opera¬ 
tionalize  and  extend  a  conventional  R  &  D  model  reveals  their  tacit  understanding  of  what  is 
described  in  business  terms  as  the  ‘Value  chain.” 


Hgure  4-2:  Concurrent  Transition  with  Stages 


Compression  of  the  larger  technology  life  cycle  can  be  descrXied  as  concurrent  technology  transitnn,  an  ap¬ 
proach  whereby  R  &  D,  product  development,  and  imfxementaton  issues  are  explored  simultaneously  by  means 
of  prototyping,  testing,  and  gathering  feedback  through  alliances  between  developers  and  end  users.  Concurrent 
technology  transition  has  the  potential  to  significantly  reduce  the  time  it  typically  takes  to  bring  a  radical  technol¬ 
ogy  (possibly  also  incremental  advancements)  to  market.  The  means  by  which  the  SEI  compresses  the  technol¬ 
ogy  life  cycle  and  leverages  the  infrastructure  is  tied  to  the  Institute’s  identity  as  an  FFRDC.  The  principle  of  le¬ 
verage  is  also  applicable  for  lor  profits,”  most  likely  through  strategic  alliances.  For  more  on  vertical  alliances, 
see  Technology  Fusnn  and  the  New  R  &  D*  by  F.  Kodama,  1 992,  Harvard  Businass  Review,  July-Aug.,  pp.  TO¬ 
TS. 
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According  to  Botkin  &  Matthews  [1 992].  the  value  chain  describes  the  proc^  by  which  a  new 
idea  gets  to  market.  The  vadue  chain  is  a  sequence  of  activities  during  which  value  is  added 
to  a  new  product  or  service  as  it  makes  its  way  from  invention  to  final  distribution.  When  a  com- 
mercialiy  valuable  idea  takes  forever  to  get  from  concept  to  marketplace— or  never  arrives — 
the  problem  is  often  a  weak  or  missing  link  (p.  26).**  The  value  chain  is  composed  of  several 
linked  stages,  which  can  ttien  be  grouped  into  three  phases: 

•  Phase  1 :  research,  development,  design 

•  Phase  2:  production  (manufacturing,  fabrication) 

•  Phase  3:  marketing,  sales,  distribution 

One  key  way  to  navigate  the  value  chain  is  through  partnerships.^  Botkin  &  Matthews 
[1 992]  illustrate  how  large  businesses  may  be  weak  innovators  and/or  slow  in  getting  products 
to  market;  nonetheless,  these  bigger  corporations  can  offer  smaller  partners  “stability  and 
credibility,  established  marketing  and  distribution  channels,  and  financial  resources  that  are 
almost  unimaginable  to  strapped  young  companies  (p.  32)."  Ideally,  companies  specializing  in 
one  phase  of  the  value  chain  would  partner  witt)  other  companies  able  to  complete  another 
phase  of  the  process.  While  RMARTS  did  not  map  a  specific  path  to  commercialization,  the 
project  intuitively  endorsed  principles  of  the  value  chain  and  partnering  through  their  notion  of 
self-sustaining  transition.  Self-sustaining  transition,  we  recall,  involved  developing  a  viable 
market  for  RMA  so  that  others  would  provide  consulting  senrices,  ensure  that  compiler  ven¬ 
dors  supported  RMA  algorithms,  build  tools,  etc. 


^  Botkin  &  Matthews  [1992]  discuss  three  additional  factors  that  influence  innovation  along  the  value  chain:  the 
drive  for  technological  breakthroughs,  total  quality  management  (TQM)  eflorts,  and  customer  focus  programs. 
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5  Method 


5.1  Design 

In  empirical  resear^,  it  is  conventional  to  talk  about  triangulation  and  to  design  studies  that 
use  converging  methods  and  measures  to  investigate  a  question  or  hypothesis.  Triangulating 
is  one  way  to  insure  reliable  data  collection  and  reduce  threats  of  invaiidity.  The  concept  is  par¬ 
ticularly  suggestive  for  research  on  technology  transition.  A  complete  understanding  of  tech¬ 
nology  transition  requires  that  one  pay  attention  to  multiple  units  of  analysis,  including  the 
technical.  Institutional,  and  cultural  grounds  for  the  adoption  and  implementation  of  innova¬ 
tions.  For  this  reason,  the  case  study  of  ttte  transition  of  RMA  was  conceived  of  in  two  parts. 
As  we  have  explained.  Part  1 ,  this  report  is  concerned  with  the  analysis  of  transition  activities 
according  to  phases  of  a  technology  maturation  life  cycle.  Part  2  examines  the  processes  of 
adoption  and  implementation.  Together,  the  two  parts  offer  a  robust  picture  of  the  transition  of 
RMA.  allowing  us  to  attend  to  development  and  user  perspectives:  to  technology  't>ush”  and 
technology  “pull."  The  more  technical  explanation  of  how  this  (two-part)  investigation  of  RMA 
can  be  seen  in  the  larger  context  of  case  study  design  follows. 

The  full  study  can  be  described  as  an  embedded  single  case  design  [Yin  1984].  In  layman’s 
terms,  the  case  study  is  about  the  transition  of  RMA;  and  the  study  involves  several  levels  of 
analysis.  The  main  unit  was  the  technology  transition  effort  as  a  whole;  the  two  smaller  sub¬ 
units  were  (Part  1 )  RMARTS  Project  transition  activities  and  (Part  2)  a  subset  of  adopters’  and 
users’  perspectives  on  the  technology.  For  Part  1  of  the  investigation,  a  combination  of  data 
collection  techniques  was  used,  ranging  from  analysis  of  historical  documents  (including 
plans,  reports,  and  statements)  to  informal  data  collection  through  the  researchers’  atten¬ 
dance  at  RMARTS  meetings  (from  September  1991  to  December  1992)  and  personal  inter¬ 
views  conducted  with  RMARTS  staff.  The  following  subsection  discusses  the  materials  and 
procedure,  including  the  coding  scheme,  used  for  Part  1  of  the  case  study.  A  separate  report 
on  sKfopters’  and  users’  perspectives  of  RMA  is  contained  in  CMU/SEI-93-TR-30. 

This  case  study  on  the  transition  of  RMA  is  best  described  as  enlightening  with  respect  to  our 
ability  to  observe  and  analyze  a  situation  not  previously  accessible  to  sdentitic  investigation, 
in  this  context  'Ihe  case  is  therefore  worth  conducting  because  the  descriptive  information 
alone  will  be  revelatory  [Yin  1984.  p.  43].”  To  date,  the  transition  of  RMA  technology  has  not 
been  the  subject  of  research.  Nor  have  software  developer  perspectives  on  transition  activities 
and  user  perspectives  on  adoption  and  implementation  been  juxtaposed  in  one  case  study.  In 
this  regard,  we  break  new  ground. 

As  is  common  with  single  (embedded  and  holistic)  case  stitoies,  we  cannot  extend  our  obser¬ 
vations  about  RMA  and  the  RMARTS  team  to  other  technologies  and  other  technical  projects. 
Emerging  theory  about  software  technology  tr^sition  must  be  tested  through  replication  of  the 
findings  in  a  second  or  third  technology  case,  where  the  theory  has  hypothesized  that  the 
same  results  should  occur.  Such  replication  logic  (attending  to  both  technology  sjid  organiza¬ 
tional  context)  plays  a  key  role  in  case  study  research  and  in  experimentation,  allowing  one  to 
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eventually  establish  “external  validity”:  the  ability  to  generalize  beyond  the  specific  instance 
[Yin  1984;  Chadwick,  Bahr  &  Albrecht  1984]. 

The  present  investigation  should  not  be  confused  witii  a  historical  study  of  RMA  transition  ac¬ 
tivities  and  the  persons  involved  with  the  same.  As  indicated,  the  issue  explored  (in  Part  1)  is 
technology  push;  thus,  we  concentrate  on  transition  according  to  the  perspectives  of  the  de¬ 
velopers  and  development,  in  addition,  because  tftis  perspective  is  revealed  through  project 
documents  and  events,  the  observations  are  those  of  the  project  as  a  “whole"  rather  than  in¬ 
dividual  members.  The  study  does  not  capture  personal  interpretations  or  records  of  the 
RMARTS  staff,  norths  views  of  others  who  are  external  to  the  SEi.  A  history  of  the  technology 
and/or  a  social  network  study  attending  to  influence  within  and  between  adopting  (and  co-de- 
veloping)  communities  would  offer  other  dimensions  of  the  RMA  story.  Such  investigations 
represent  promising  directions  for  further  research. 

5.2  Materials  and  Procedure 

As  indicated,  the  main  unit  of  analysis  was  the  technology  transition  effort  as  a  whole;  and  the 
two  subunits  consisted  of  (Part  1)  RMARTS  Project  transition  activities  and  (Part  2)  a  subset 
of  adopters’  and  users’  perspectives  on  the  technology.  At  each  level  of  the  analysis,  multiple 
data  collection  techniques  were  used,  ranging  from  the  analysis  of  historical  documents  or  ar¬ 
tifacts  (including  plans,  reports,  and  statements)  to  informal  data  gathering  through  the  re¬ 
searchers’  attendance  at  RMARTS  meetings  (from  September  1991-  December  1992)  and 
personal  interviews  conducted  with  RMARTS  staff. 

Primarily,  data  were  collected  through  the  analysis  of  historical  documents.  These  documents 
consisted  of 

•  Reports  of  project  accomplishments  in  the  annual  SEI  one  and  five  year 
plans,  spanning  from  1988  (when  the  Real-Time  Scheduling  in  Ada  Project 
was  first  reported  on  for  1987)  until  the  present  plan  for  1993  (reporting  on 
1992  accomplishments). 

•  Two  quarterly  reports  on  the  first  half  of  1 993. 

Transition  activities  for  RMA  were  coded  according  to  phases  of  the  technology  maturation  life 
cycle  as  represented  in  the  RMARTS  transition  model.  Figure  5-1  shows  a  sample  year  of  cod¬ 
ing,  with  1988  data  presented.  (The  complete  year-by-year  analysis  is  provided  in 
Appendix  A.) 


16 


CMU/SEI-93-TR-29 


The  coding  procedure  included  the  following; 

•  Review  of  the  Real-Time  Scheduling  in  Ada  (RTSIA)  and  later  tfie  RMARTS 
sections  of  the  annual  SEI  one  and  five  year  plan,  in  which  the  previous 
year's  accomplishments  were  listed. 

•  Separation  of  the  prose  descriptions  of  all  consequential^  accomplishments 
into  discrete  activities. 

•  Assignment  of  each  discrete  activity  to  a  life-cycle  phase. 

•  Distribution  of  copies  of  the  summary  of  activity  assignment  to  all  project 
members. 

•  Meetings  to  review  assignments  with  a  minimum  of  three  project  members. 

•  Revision  of  assignments  of  activities  based  on  reviews. 

The  reliability  of  the  coding  was  tested  in  two  ways.  First,  where  possible,  we  examined  sup¬ 
porting  documents,  including  quarterly  and  technical  reports,  project  summaries,  and  journal 
articles  to  cross-check  accuracy  of  activities  and  events;  second,  RMARTS  Project  members 
reviewed  our  coding  efforts  for  1987-1993  and  the  draft  case  study  report.  The  latter  review 
by  RMARTS  Project  members  (who  might  typically  be  referred  to  as  “key  informants")  is  im¬ 
portant  in  testing  the  connect  operational  measures  for  the  concepts  being  studied  here.  Tech¬ 
nically  speaking,  this  is  referred  to  as  construct  validity. 

Two  additional  data  collection  methods  must  be  noted.  First,  we  attended  RMARTS  Project 
staff  meetings  from  September  1991  until  the  close  of  the  project  in  December  1992.  These 
meetings  provided  the  opportunity  to  gather  informal  background  on  RMARTS  activities.  In 
January  1993,  the  main  responsibility  for  RMA  transition  was  officially  handed  off  to  another 
function  within  the  Institute,  to  Pror^cts  and  Services  Planning  (P  &  SP).  From  January  1993 
until  the  present,  we  continued  to  meet  with  Ray  Obenza,  the  P  &  SP  staff  member  dedicated 
to  RMA.  Second,  in  the  winter  of  1993,  we  conducted  a  set  of  interviews  with  the  RMARTS 
Project  to  investigate  the  evolution  of  the  RMARTS  transition  model.  We  were  particularly  in¬ 
terested  in  the  model's  relation  to  other  technology  maturation  life  cycles.  These  interviews 
also  allowed  us  to  explore  project  history  and  strategy  and  to  translate  technical  material  into 
layman's  terms. 


^  Each  coded  activity  was  assumed  to  require  a  minimum  of  one  staff  month  of  effort  to  accomplish.  Most  activities 
required  substantially  more  effort. 
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Promising 

Tschnology 

S«l«ct«d 


(Is  it  potentially 
relevant?) 


Key  Limitations 
Addressed 


(Is  it'pbteritially' 
practical?) 


Value  and 

Transitionability 

Denwnstrated 


(Is  it  easily'  l^neif 
and/or  buiK?) 


Self-Sustaining 

Transition 


Widespread 

Use 


(What  support  fs' ' 
needed  for  sustained 
usage?) 


(Can  it  become 
common  practice?) 


Reports  for  compiler 
vendors  about 
implementing 
algorithms  for  Ada 
runtime  systems. 

Development  of 
theory  implementation 
validation  and 
performance  tests. 

Analysis  of  Real-Time 
Emb^ed  Systems 
Testbed  (RESl) 
Project's  Inertial 
Navigation  System  for 
refinement  of  theory. 


IBM  resident  affiliate 
arrives. 

Naval  Weapons 
Center  (NWC) 
resident  affiliate 


IBM  resident 
affiliate  in 
collaboration  with 
Sr.  IBM  engineers 
prepares  material  for 
IBM-internal  RMS 
course. 

Generic  avionics 
case  study  developed 
by  IBM  and  NWC. 

Naval  Wet^ns  Ctr 
resident  affiliate 
developing  generic 
missile  case  study. 

Representation  of  the 
avionics  system 
implemented  using 
modified  Verdix 
Ada  compiler  to 
determine  if 
predicted  performance 
can  be  obtained. 


Work  with  hardware  One-day  tutorial 
bus  standards  groups  prepared  to  give  to 
(IEEE  FutureBus4')  ermineers  at  SEI 
to  allow  effective  use  Affiliates  Symposium, 
of  prioritized  schedul¬ 
ing  algorithms. 

Verdix  implements 
RMS-required 
scheduling  algorithms 
in  its  Ada  runtime 
system. 


Other  compiler 
vendors  experiment¬ 
ing  with  the 
al^rithms. 

Work  with  /Vda 
language 
maintenance  and 
revision  efforts. 

Documents  for 
project  managers. 


I  experimei 
I RTCN  at  I 


Figure  5-1: 1988  Activities 
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6  Results 


The  heterogeneity  of  RMARTS  transition  strategies  and  activities— involving  different  commu' 
nities.  forums,  and  mechanisms— makes  it  necessary  to  describe  RMARTS  from  a  number  of 
perspectives.  Thus,  the  following  discussion  is  divided  into  key  topic  areas: 

•  Vision 

•  Standards  work 

•  Range  and  pattern  of  transition  activity 

6.1  Vision 

The  consistency  with  which  RMA  progressed  through  the  stages  of  transition  was  not  seren¬ 
dipitous.  Goodenough’s  and  Sha's  vision  for  RMA  is  stated  in  the  introduction  to  the  RMARTS 
annual  plan.  In  1988,  the  plan  reads: 

The  overall  objective  of  this  project  is  to  transition  advanced  real¬ 
time  scheduling  theory  into  routine  software  engineering  practice  in 
the  context  of  Ada.  After  tfiis  transition  is  accomplished,  real-time 
systems  will  be  developed  using  a  set  of  theoretically  sound  real¬ 
time  scheduling  algoritfims  implemented  in  a  runtime  scheduler. 

These  algorithms  will  guarantee  that  all  timing  constraints  will  be 
met  by  the  system  as  long  as  the  use  of  computing  resources  is  less 
than  a  certain  bound.  In  addition,  when  a  transient  system  overload 
occurs,  deadlines  will  be  missed  in  a  predefined  order  of  mission 
criticality. 

The  specificity  of  the  discussion  is  noteworthy:  the  vision  is  operationalized  in  concrete  terms, 
reflecting  what  the  theory  was  able  to  do. 

Later  in  the  same  plan,  we  see  the  following: 

Besides  improving  the  state  of  the  practice  of  real-time  software  en¬ 
gineering,  this  project  is  intended  to  demonstrate  that  the  SEI  can 
improve  software  engineering  by  reducing  the  time  needed  to  tran¬ 
sition  theoretical  notions  into  practice. 

This  previous  remark  then  continues  to  appear  in  subsequent  plans. 

We  are  able  to  observe  how  the  statement  of  project  purpose  is  tuned,  in  concert  with  the 
evolving  vision.  In  1989  and  1990,  it  reads: 

The  purpose  of  the  Real-Time  Scheduling  In  Ada  Project  is  to  tran¬ 
sition  a  new,  analytic  approach  for  designing  real-time  systems  into 
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routine  software  engineering  practice,  particularly  for  systems  im¬ 
plemented  in  Ada. 

The  emphasis  on  Ada  was  found  to  be  deflecting  the  attention  of  potential  users  from  the  fact 
that  the  theory  did  not  depend  on  Ada.  Therefore,  in  1991  the  projerft  name  changes  from 
Real-Time  Scheduling  in  Ada  to  Rate  Monotonic  Analysis  for  Real-Time  Systems.  Moreover, 
linking  the  work  to  Ada  was  not  helping  to  make  the  technology  more  transitionable;  it  tended 
to  raise  questions  that  ultimately  proved  irrelevant  to  the  adoption  process.  The  name  change 
also  reflected  the  project’s  understanding  that  the  theory  had  a  broader  range  of  application 
than  was  originally  understood.  In  particular,  the  project  came  to  realize  tiiat  the  theory  could 
be  used  to  analyze  the  behavior  of  systems  that  had  not  been  designed  or  implemented  with 
the  theory  in  mind.  In  this  sense,  the  project  was  lucky  to  have  picked  a  theory  that  turned  out 
to  apply  so  broadly.  Now.  in  1991 .  the  purpose  statement  for  the  project  reads 

...to  improve  the  state  of  the  practice  for  real-time  systems  engi¬ 
neering  by  providing  a  solid  scientific  foundation  for  dealing  with  tim¬ 
ing  behavior  of  real-time  systems. 

Rate  monotonic  scheduling  theory  is  presented  as  the  technology  of  choice  for  accomplishing 
this;  and  the  project  is  no  longer  “focused  primarily  on  scheduling  algorithms...”  because  of  the 
realization  that  the  theory  could  be  applied  more  widely  than  was  previously  understood. 

The  existence  of  a  vision,  its  operational  definition  and  maintenance,  and  its  concentration  on 
transition  were  key.  The  vision  (and  the  activities  that  inform  it)  is  important  for  three  reasons: 
its  breadth,  contribution  to  project  management,  and  evolutionary  nature.  First,  the  vision  is 
tuned  to  represent  the  technology  in  an  attractive  and  broadiy  applicable  light.  According  to 
one  project  member,  early  interaction  at  RMARTS  staff  meetings  resulted  in  an  increasingly 
refined  understanding  of  the  audiences  for  RMA.  For  example,  the  team  determined  that  tiie 
connection  to  Ada  was  important  but  not  prims^.  The  purpose  of  the  project’s  name  change 
was  to  broaden  the  audience  and  to  ensure  that  application  of  the  technology  was  not  limited 
to  the  Ada  context. 

Second,  the  consistency  and  specificity  of  the  vision,  even  as  it  evolved,  was  integral  to  project 
management.  Based  on  our  observations  at  RMARTS  staff  meetings,  each  member  appeared 
to  have  internalized  the  vision  and  to  have  made  decisions  consistent  with  it.  Actions  were  re¬ 
ported  at  staff  meetings  where  consistency  with  the  vision  was  checked  informally  and  feed¬ 
back  was  provided.  Over  time,  the  effect  was  that  of  a  coordinated  team  with  individuals 
working  autonomously,  all  moving  toward  the  common  goal.  Eventually,  the  RMARTS  stage 
model  of  transition  was  developed  and  formalized  to  describe  what  the  project  had  done  and 
was  planning  to  do. 

Finally,  the  vision  was  not  static  or  cast  solely  in  terms  of  the  state  of  the  technology;  the  vision 
grew  along  with  RMARTS  Project  members’  considerable  capability  as  change  agents.  Each 
year’s  plan  presents  material  on  transition  action  to  be  taken.  In  the  1990  and  1991  plans,  sep- 
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arate  sections  appear  for  technology  insertion/sKjoption  tasks”  and  for  transition  plans.” 
Tasks  include  technical  work,  but  also  highly  leveraged  transition  work,  such  as  he^^ing  with 
the  Navy’s  Next  Generation  Computer  Resource  (NGCR)  standards  development  and  finding 
vendors  for  commerdai  distribution,  training,  and  consulting. 


6.2  Standards  Work 

Standards  efforts  represent  a  high-ievers^e  activity  for  improving  computing  and  software  en¬ 
gineering  since  they  are  community  efforts,  developed  and  distributed  by  organizations  such 
as  IEEE  (Institute  of  Electrical  and  Electronic  Engineers),  ANSI  (American  National  Standards 
Institute),  NIST  (National  Institute  of  Standards  and  Technology)  and  ISO  (International  Orga¬ 
nization  for  Standardization).^^  Standards  take  years  to  reach  offidal  approval  with  multiple 
intermediate  drafts  drculated  for  comments  and  voting  by  the  technical  community;  however, 
RMARTS  recognized  the  importance  of  contributing  to  precompetitive  consensus  building  and 
to  standards  efforts. 

Using  standards  to  transition  technology  allows  one  to  take  advantage  of  mechanisms  for  dis¬ 
semination  that  are  already  in  place.  Craig  Meyers,  of  RMARTS.  comments:  ‘ANhen  we  work 
on  an  IEEE  standard,  IEEE  takes  care  of  publishing  the  standard,  and  they’re  the  ones  who 
route  it  to  ANSI  and  ISO.  The  preexistence  of  mechanisms  to  advertise,  publish,  and  dissem¬ 
inate  make  transition  much  easier  for  us.  And  when  vendors  whose  products  conform  to  the 
standards  begin  to  advertise  product  features  using  the  terminology  of  the  technology,  we  get 
more  free  leverage."^®’ 

Standards  that  might  potentially  block  a  technology  need  to  be  modified  to  permit  or,  ideally, 
to  support  the  adoption  of  that  technology.  Activities  throughout  the  life  of  RMARTS  demon¬ 
strate  understanding  of  standards  as  a  means  of  reducing  barriers  to  technology  adoption.  In 
the  case  of  RMA,  multiple  standards  efforts  were  pursued  (see  Appendix  A).^^  As  early  as 
1988,  RMARTS  began  to  work  with  hardware  bus  standards  groups  (IEEE  P896.3  Future- 
Bus-*-)  to  allow  effective  use  of  prioritized  scheduling  algorithms.  These  efforts  continued 
through  1 988-1 989;  and  in  1 990,  two  related  papers  were  published.  These  papers  addressed 


Formal  standards  cannot  ba  ovarastimatad  as  a  high-iavaraga  transition  activity.  IEEE  tracks  its  standards  to 
bacoma  US  national  standards  through  ANSI,  which  puts  tham  on  tha  path  to  bamming  intarnational  standards 
through  ISO.  Working  with  IEEE  standards,  than,  laads  to  standardization  in  tha  international  marketplaca,  the 
broadest  possible  arena  of  influence. 

Personal  interview  with  RMARTS  Project  member  Craig  Mayers,  conducted  by  Bill  Poliak,  July  1993. 

Ted  Baker,  resident  affiliate  with  RMARTS  from  1991-92,  works  with  three  standards  efforts:  Ada9x 
Mapping/Revision  Team,  POSIX  (portable  operating  system  interface)  working  group  (WG)  IEEE  PI  003.4  (de¬ 
veloping  standards  for  real-time  operating  system  services),  and  POSIX  WG  IEEE  P1003.5  (deveicping  standard 
Ada  language  bindings  for  the  POSIX  standards).  Since  1991,  Michael  Gonzilaz  Harbour  rd  the  Universidad  de 
Cantabria,  visiting  scientist  with  RMARTS  from  1 991-1992,  has  also  been  active  with  POSIX  WG  IEEE  P1003.4. 
John  Goodertough  has  been  a  key  contributor  to  dewlopment  of  the  Ada9X  programming  language  standard. 
Craig  Meyers  is  chair  of  a  working  group  that  is  writing  a  POSIX  standard  (IEEE  PI 003.21)  for  real-time  distrib¬ 
uted  systems  communication.  In  addition,  Meyers  has  been  active  in  the  SAFENET  (survivdble  adaptable  fiber 
optic  embedded  network)  Working  Group  and  IEEE  PI  003.12,  Protocol  IrufeperKlent  Interfaces  for  Interprocess 
Communication  Working  Group.  Meyers  and  Lui  Sha  pankripated  in  the  NG(^  Real-Time  Working  Group  (fo¬ 
cused  on  system  integration).  Sha  has  led  and  been  active  in  P896.3  standardization  efforts  for  IEEE  FutureBus+. 
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design  issues  concerning  support  for  real-time  s^tem  development  based  on  rate  monotonic 
scheduling  and  the  IEEE  FutureBus-t-.  Also  in  1990,  the  System  Design  Manual  iw  IEEE  Fu- 
tureBus-f  included  a  chapter  on  how  to  use  the  FutureBus-t-  when  designing  real-time  systems 
based  on  RMA.  Particularly  interesting,  here,  is  the  way  that  the  RMARTS  team  used  conver¬ 
gent  vehicles  for  transition.  For  example,  the  standards  work  was,  initially,  a  mechanism  for 
getting  the  technology  adopted;  it  was  later  realized  that  the  standardization  process  itself  was 
also  a  mechanism  for  disseminating  technical  information  and  its  utility:  first,  by  explaining  it 
to  the  members  of  the  standardization  group  and  convincing  them  to  use  the  theory  in  aeating 
a  standard;  and  second,  by  increasing  interest  in  the  theory  when  people  heard  about  the  the¬ 
ory's  presence  in  the  standard. 

FutureBus-f  was  not  the  only  standards  effort,  in  1990,  RMARTS  members  were  active  in  the 
Navy's  Next  Generation  Computing  Resources  (NGCR)  SAFENET  (survivable  adaptable  fi¬ 
ber-optic  embedded  network)  Working  Group  and  the  Real-Time  Working  Group,  also  under 
NGCR,  which  was  focused  on  system  integration.  1992  activities  included  partidpation  with 
two  other  portable  operating  system  interface  (POSIX)  efforts:  Real-Time  Distributed  System 
Communication  (IEEE  PI  003.21)  and  Protocol  Independent  Interfaces  for  Interprocess  Com¬ 
munication  (IEEE  PI  003.12).  Standards  efforts  also  included  work  on  Ada  language  mainte¬ 
nance  and  revision  (1988);  and  activity  to  influence  the  Ada9X  programming  language 
standard  to  encourage  use  of  RMA  algorithms  (begun  in  1990).  (References  to  the  complete 
set  of  standards  activities  are  provided  in  Appendix  A.) 

Of  the  total  of  132  activities  coded,  15  (about  1 1%)  were  related  to  standards,  including  IEEE 
FutureBus+,  POSIX,  and  Ada  9X. 

The  catalogue  of  standards  activity  alone  does  not  capture  the  strategic  intent  of  the  RMARTS 
Project— to  integrate  standards  into  the  vision.  Goodenough  summarizes  this  intent  here: 

For  RMA,  you  couldn't  get  these  scheduling  concepts  actually  used 
until  you  permeated  all  the  places  in  which  they  were  needed,  which 
meant  having  them  supported,  or  at  least  not  blocked,  by  the  pro¬ 
gramming  language,  the  operating  system,  and  the  local  area  net¬ 
work. 

If  you  want  to  get  the  technology  into  use,  you  have  to  ensure  that 
the  relevant  standards  that  might  block  the  technology  are  modified 
to  permit  it  or  ideally,  to  support  it.  In  the  beginning  we  found  lots  of 
people  saying,  '^Ne\\,  thafs  a  great  idea,  but  my  operating  system 
doesn't  support  it;  what  can  I  do  about  if?  That's  when  we  began  to 
focus  on  how  people  could  use  RMA  even  if  their  operating  system 
didn't  support  it.  That  was  one  of  the  reasons  for  dealing  with  stan¬ 
dards  right  in  the  beginning. 
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One  of  the  first  things  we  did  was  say.  “How  can  we  interpret  the 
Ada  standard  to  allow  an  operating  system  to  conform  to  the  stan¬ 
dard  and  still  to  support  RMA  scheduling?”  In  fact,  some  of  my  first 
presentations  on  RMA  were  to  people  involved  in  the  ADA  Lan¬ 
guage  Maintenance  Committee  so  that  they  would  be  sympathetic 
to  viewing  this  broader  interpretation.  Provoking  the  issues  in  a 
standards  context  caused  people  to  pay  much  more  attention  so 
that  we  could  persuade  them. 

The  fact  that  RMA  concepts  appeared  in  the  Ada9X  standard  and  in 
the  POSIX  standards  gave  them  an  inherent  credibility,  it  meant  fiiat 
these  ideas  had  been  debated  among  industry  people  who  aren’t  in¬ 
terested  in  any  ideas  unless  they  actually  help  them  out.  The  fact 
that  these  ideas  were  being  discussed  in  a  standards  committee, 
which  is  generally  composed  of  people  who  are  influential  within 
their  companies  and  within  their  fields,  meant  that  these  ideas  were 
reaching  key  opinion  makers.  It’s  like  targeting  your  technology  to 
the  people  who  will  make  the  most  difference.  When  other  people 
see  them  in  the  standard,  they  begin  to  say.  “Gee,  what  is  this  stuff? 

I  ought  to  know  about  it  because  it’s  passed  this  hurdle  of  being  ac¬ 
cepted.”  So,  in  terms  of  generating  awareness  of  a  technology, 
standards  are  an  excellent  vehicle.^^ 

A  final  point  about  standards  activity  is  important.  Many  readers  of  this  case  study  will  be  work¬ 
ing  in  business  enterprises  where  technology  development  and  transfer  are  directly  related  to 
market  share  and  profit  motive.  The  SEI  has  neither  such  relationship;  and  the  lack  of  this  re¬ 
lationship  had  a  direct  and  positive  effect  on  the  RMA  success  with  standards  organizations. 
The  point  is  worth  underscoring  for  two  reasons:  first,  the  SEI  occupies  a  special  and  unusual 
position;  second,  in  order  to  follow  the  RMA  example,  commercial  organizations  will  have  to 
overcome  the  assumption  that  tfiey  are  motivated  solely  by  profit.^^ 

6.3  !^ange  and  Pattern  of  Transition  Activity 

In  any  particular  year  of  the  RMA  transition  dironology,  one  or  two  themes  dominate.  For  ex¬ 
ample,  in  1987  most  of  the  activities  address  key  barriers  to  adoption  of  the  technology;  and 
in  1988  technical  partnerships  and  collaboration  are  a  dominant  theme.  Together,  the  variety 
of  transition  activities  for  the  first  two  years  of  RMARTS  is  unusual.  In  the  following  brief  dis¬ 
cussion.  we  comment  on  the  range  of  transition  activities  and  important  patterns  that  we  see, 
from  1987  through  1993. 


Personal  interview  with  John  Goodenough  conducted  by  Bill  Poliak,  July  1993. 

Personal  conversation  with  Tom  Ralya,  November  1993. 

CMU/SEI-93-TR-29  » 


In  1 987,  «vhile  the  ntaJn  thrust  of  c^tMties  address^  the  technical  limitations,  IBM  is  deploying 
hardware/software  with  periodic-only  rate  monotonic  scheduling  (RMS),  in  1988,  two  resident 
affiliates,  one  from  Naval  Weapons  Center  and  one  from  IBM,  are  on  board;  the  IBM  affiliate, 
collaborating  with  senior  engineers  back  home,  is  preparing  material  for  an  IBM  intemaJ 
course.  Also  in  1988,  several  compiler  vendors  are  experimenting  with  rate  monotonic  sched¬ 
uling  algorithms;  and  RMARTS  has  started  to  work  with  a  hardware  bus  standards  group  to 
allow  effective  use  of  prioritized  scheduling  algorithms. 

in  1988  and  1989,  collaboration  with  a  single  large  organization,  IBM,  accounts  for  roughly 
25%  of  total  activities.  Most  significant  are  the  arrival  of  the  IBM  resident  affiliate,  preparation 
of  an  IBM  internal  course  by  the  affiliate,  development  of  the  generic  avionics  case  study  (with 
the  Naval  Weapons  Center  resident  affiliate),  and  application  of  RMA  to  the  BSY-1  Team 
Trainer  system.  In  interviews.  Goodenough  indicated  that  the  choice  of  one  large  influential 
organization  was  part  of  the  transition  strategy  for  RMA.  the  idea  being  to  establish  credibility 
by  association  as  well  as  to  take  advantage  of  tfie  substantial  engineering  expertise  offered 
by  the  organization. 

By  1990,  several  organizations  are  actively  involved  with  the  project;  IBM  continues,  but  now 
the  Navy,  General  Electric,  and  the  Space  Station  Project  (including  contractors  such  as  Mc¬ 
Donnell  Douglas.  Honeywell,  and  the  Research  Institute  for  Computing  and  Infomnation  Sys¬ 
tems  [RICIS])  are  also  engaged.  Again,  the  strategy  is  to  use  the  influence  of  the  large 
organizations  to  draw  attention  to  RMA.  Also  in  1990,  the  European  Space  Agency  (ESA)  On- 
Board  Data  Division  announces  plans  to  use  RMA  as  the  baseline  methodology  for  its  hard 
real-time  operating  systems  project.  While  the  source  of  the  connection  to  the  ESA  is  not 
known,  its  plans  signal  the  extent  to  which  word  about  RMA  is  spreading.  This  may  indicate 
that  the  “influence”  strategy  is  working. 

Standards  work,  discussed  at  length  above,  which  began  in  1988  and  1989,  picks  up  steam 
in  1 990  and  1 991 .  The  reference  to  an  engineering  handbook  first  appears  in  1991 .  The  hand¬ 
book  is  worked  on  intensively  in  1 992,  culminating  in  publication  by  Kiuwer  Academic  Publish¬ 
ers  in  1993  of  A  Practitioner's  HancBjook  for  Real-Time  Analysis:  Guide  to  Rate  MonotonIc 
Analysis  for  Real-Time  Systems.^ 

Also  in  1 990  and  1991,  Navy  support  for  work  with  General  Electric^  provides  extensive  op¬ 
portunity  to  understand  and  refine  the  introduction  process  for  the  technology.  This  includes 
development  of  an  RMA  workshop  approach  that  gives  students  hands-on  experience  apply¬ 
ing  the  method,  and  development  of  data  sheets— templates  for  collecting  information  about 
each  task  that  is  needed  to  perform  a  timing  suiaiysis.  A  modification  of  the  data  sheet  ap¬ 
proach  was  incorporated  into  the  handbook  later,  in  1992. 


Goodenough  notes  that  the  idea  of  a  handbook  appeared  much  earlier,  in  a  draft  plan  that  he  prepared  in  1987. 
He  had  a  ‘long-term  goal  of  putting  the  output  of  projects  into  handbooks.*  Personal  correspondence  with  John 
Goodenough,  CX:tober  1993. 

RMARTS  Project  member  Mike  Gagliardi’s  engineering  background  was  essential  in  his  work  with  GE;  he  had 
credibility  as  a  practicing  engineer  and  could  answer  questions  from  that  viewpoint.  He  was  seen  by  his  students 
as  one  of  them.  Moreover,  he  had  worked  on  the  GE  project  and  was  recognized  as  a  trustworthy  authority. 
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Whereas  technical  partnerships  were  key  in  1 988.  partnerships  involving  distrttxjtion  are  com¬ 
mon  in  1992.  These  partnerships  focus  on  diffusion  and  creation  of  the  whole  product  [Moore 
1991]  for  RMA— tools,  commercial  training,  courses,  videotapes,  and  the  RMA  handbook.  For 
example,  students  from  the  Carnegie  Mellon  University  Masters  in  Software  Engineering  Pro¬ 
gram  collaborate  with  RMARTS  to  develop  a  real-time  analysis  tool.  Kluwer  is  engaged  to  pi^- 
lish  the  handbook.  Companies  that  give  technology  training  courses  are  pursued  to  encourage 
them  to  give  RMA  training  courses.  Telos  arxl  Tri-Pacific  were  eventually  selected  and  signed 
agreements  with  the  SEI  enabling  the  development  of  commercial  courses  on  RMA  (which 
were  then  listed  in  SEI’s  Products  and  Sen/ices  portfolio).  These  two  companies  also  sponsor 
booths  at  the  SEI  SofhMare  Engineering  Symposium.  Ruth  Ravenel  of  the  University  of  Colo¬ 
rado  begins  development  of  a  short  video-based  course,  with  project  cooperation.  An  agree¬ 
ment  with  the  Software  Productivity  Consortium  (SPC)  is  negotiated  to  allow  incorporation  of 
RMA  into  the  Software  Productivity  Consortium  (SPC)  ADARTS*^  methodology.  The  user 
community,  at  the  instigation  of  the  SEI  and  as  part  of  the  RMARTS  self-sustaining  transition 
strategy,  begins  to  be  organized  through  the  first  RMA  Users  Forum  in  September  1992. 

Finally,  several  general  observations  are  in  order.  Throughout,  RMARTS  members  were  at¬ 
tentive  to  the  notion  of  leveraging  the  infrastructure.”  an  idea  frequently  discussed  at  the  SEI 
during  its  first  few  years.  As  we  have  indicated,  the  idea  was  to  expedite  "self-sustaining  tran¬ 
sition”  of  RMA  so  that  project  members  could  discontinue  inten/entions  and  move  along  to  de¬ 
termining  and  developing  the  next  "promising  technology.”  The  decision  to  end  the  project  was 
made  18  months  before  the  scheduled  termination  of  the  project,  and  the  stage  model  was 
explicitly  used  to  focus  efforts  during  this  1 8-month  period  on  achieving  self-sust£tining  transi¬ 
tion.  High-leverage  activities,  such  as  partnerships  for  co-deveiopment  and  distribution,  were 
selected  and  chosen  with  this  goal  in  mind.  Hence  the  focus  on  training  partners  and  on  cap¬ 
turing  existing  knowledge  about  RMA  in  a  handbook.  Both  RMARTS  and  its  partners  benefited 
from  the  arrangement.  More  examples  of  ttiis  can  be  seen  in  the  "self-sustaining  transition” 
phase  in  Appendix  A. 

Project  members  understood  the  need  to  reduce  risk  for  potential  partners.  For  example,  in 
the  case  of  workshops  in  the  application  of  RMA.  RMARTS  developed  material  and  delivered 
sufficient  offerings  themselves  to  understand  the  type  of  training  needed.  They  did  not.  how¬ 
ever.  provide  ongoing  delivery  for  the  course,  but  recruited  (or  supported  volunteer)  training 
groups  such  as  the  IBM  corporate  education  organization,  RICIS  training  for  NASA  personnel, 
and  Telos  and  TriPacific  as  commercial  suppliers.  In  contrast,  tool  development  has  pro¬ 
gressed  much  more  slowly,  perhaps  because  there  are  more  work  and  resources  involved  in 
taking  an  SEI-developed  prototype  tool  and  creating  a  commercial-grade  product  than  in  tak¬ 
ing  training  materials  and  upgrading  them  to  a  commercial-quality  course.^'' 


'  The  work  on  tool  development  was  limited  to  the  development  of  a  calculation  program  that  was  distributed  to 
interested  parties  on  request  with  the  advice  that  it  was  only  an  example  of  what  could  be  done.*  In  retrospect, 
Goodemugh  comments:  *We  explicttly  decided  not  to  focus  on  tool  development  because  rther  areas  seemed 
to  have  higher  leverage.  Since  we  didn’t  have  the  resources,  we  hoped  that  by  staying  back,  some  commercial 
vendor  might  jump  in  and  provide  a  tool.  But  if  we  had  had  more  resources,  we  might  have  provided  a  tool.'  Per¬ 
sonal  correspondence  with  John  Goodenough,  October  1993. 
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In  reviewing  transition  activities  from  1 987  to1 993.  we  are  able  to  obsenre  how  the  type  of  tran¬ 
sition  activity  changed  during  the  life  of  the  project  Over  time,  effort  spent  on  extending  the 
technology  itself  diminished  and  effort  expended  on  demonstrating  the  usefulness  of  the  tech¬ 
nology  inaeased.  Similarly,  in  Vne  later  years,  more  and  more  effort  was  dedicated  to  “lever¬ 
aging  the  infrastructure"  and  disseminating  the  technology  to  the  broader  population  of 
candidate  users.  By  1993,  SEI  involvement  was  limited  to  transition-specific  activities  such  as 
the  RMA  Users  Forum  and  A  Practitioner's  Handbook  for  Reai-Time  Analysis:  Guide  to  Rate 
MonotonIc  Analysis  for  Real-Time  Systems.  At  this  time,  the  set  of  transition  activities  has  mi¬ 
grated  out  of  RMARTS  and  into  Products  and  Services  Planning.  Figure  6-1  summarizes  a  six 
and  one-half  year  chronology  of  activity  related  to  the  transition  of  RMA.^^  Each  unit  in  each 
of  the  cells  of  the  matrix  represents  a  significant  project  activity,  such  as  the  arrival  of  a  resi¬ 
dent  affiliate  at  the  SEI  or  the  publication  of  a  technical  paper. 


In  Section  5,  Method,  Figure  5-1  shows  complete  information  tor  1988;  Appendix  A  includes  details  for  all  years. 
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Figure  6-1 :  Summary  of  RMA  Activities 

A  number  of  Int^restcng  patterns  appear  when  ttie  data  are  viewed  In  this  summary  form.  First, 
the  level  of  effort  increased  in  each  year  of  the  RMARTS  Project  through  1991.  Second,  in 
each  year,  activities  occurred  in  at  least  three  of  the  five  life  cycle  phases,  belying  any  assump¬ 
tions  about  linearity  of  progress  across  the  phases.  In  this  regard,  we  note  that  the  RMARTS 
transition  model  and  our  manner  of  coding  have  allowed  us  to  override  limitations,  such  as  lin¬ 
earity.  typically  associated  with  stage  models  of  technology  development. 

A  crude  estimate  of  activity,  assuming  each  unit  is  approximately  equivalent,  shows  total  ac¬ 
tivity  nearly  doubling  from  'Value  and  transitlonability  demonstrated”  to  the  "self-sustaining” 
phase;  and  the  total  remaining  fairly  steady  from  the  "self-sustaining”  to  “widespread  use” 
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phases.  Viewed  chronologically,  number  of  activities  per  year  increased  steadily  until,  in  1 991 , 
number  of  activitlM  was  about  five  times  that  of  1987.  In  1992  and  1993  the  activity  level 
dropped  off.  This  is  because,  as  we  have  noted,  at  the  end  of  1992  RMARTS  doses  down, 
maintaining  that  self-sustaining  transition  had  been  reached;  and  in  1 993,  RMA  transition  sup¬ 
port  continued  through  Products  and  Services  Planning.  Given  the  limited  resources  of  the  SEI 
and  its  concern  with  leverage,  the  smaller  number  of  activities  in  the  Widespread  use”  phase 
is  not  surprising. 


Figure  6-2  presents  the  total  count  of  transition  activities,  year  by  year. 


Figure  6-2:  Transition  Activity  Counts  by  Year 

This  is  a  somewhat  different  representation  of  the  information  conveyed  in  Figure  6-1 ,  the 
summary  of  activities.  It  is  important  to  note  that  at  the  same  time  SEI  activities  began  to  fall 
off,  in  1 992  and  1 993,  activities  on  the  part  of  external  agents  (beyond  the  scope  of  the  present 
study)  began  to  rise.  For  example,  in  1992  Telos  and  Tri-Pacific  began  investing  their  own  re¬ 
sources  to  develop  commerdal  training  for  RMA.  Similarly,  in  1993.  Kluwer  was  contributing 
resources  to  the  produdion  of  the  RMA  handbook. 
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A  comment  on  the  shape  of  Figure  6-2  is  in  order.  Of  interest  is  the  resemblance  between  the 
curve  here  and  the  standard,  commonly  held,  adopter  population  profile,  including  innovators, 
early  adopters,  early  majority,  late  majority,  and  laggards.  [Rogers1983].  We  cannot  elaborate 
on  external  activities  for  1 992  and  beyond  to  fully  account  for  ttie  (development-related)  adopt¬ 
er  population  for  RMA.  and  the  relationship  between  this  curve  and  the  adopter-population 
profile  is  speculative;  however,  the  similarity  suggests  a  provocative  line  of  inquiry.  Technolo¬ 
gy  developers,  co-developers,  and  collaborators  may  welt  share  some  of  the  characteristics 
typically  associated  with  adopters  or  consumer — the  less  mature  the  technology,  the  greater 
the  need  for  partners  who  are  innovators  or  early  adopters  [Rogers  1983]. 

Finally.  Figure  6-3  provides  an  overall  picture  of  how  primary  transition  activities  related  to 
each  other  over  time.  This  representation  was  constructed  by  RMARTS  member  Tom  Ralya 
and  Mario  Barbacci.  manager  of  the  SEI  Real-Time  Systems  Program,  the  program  in  which 
RMARTS  was  located. 
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Monotonic  Analysis  History  Highlights 


7  Discussion 


What  can  be  learned  from  the  RMA  case  study?  As  might  be  expected,  the  results  of  the  study 
have  implications  for  a  range  of  individuals  and  the  different  types  of  organizations  with  which 
they  are  affiliated.  In  the  following  Discussion  section,  we  comment  briefly  on  implications  for: 
developers;  managers  of  R  &  D,  including  funding  ^ents;  and  researchers.  We  offer  a  final 
observation  on  the  contribution  that  research,  especially  the  case  study,  makes  to  a  greater 
understanding  of  technology  transition. 

7.1  Implications  for  Developers  of  Maturing  Technologies 

Key  issues  in  this  area  include: 

•  The  mix  of  skills  and  benefits  of  an  interdisciplinary  team. 

•  Variety  of  transition  mechanisms. 

•  Project  vision. 

•  Partnerships  for  development  and  distribution. 

Technologists  working  with  less  mature  or  maturing  technologies  must  use  a  variety  of  skills. 
The  RMARTS  Project’s  use  of  different  types  of  technical  people,  including  a  resident  affiliate 
from  an  influential  organization,  academics,  engineers,  and  mathematicians  fostered  the 
crossing  of  engineering-related  boundaries. 

A  larger  gap  existed  between  those  in  technical  disciplines  and  those  in  "softer”  disciplines, 
such  as  marketing,  management,  technical  communication,  and  training;  and  within  the  SEI, 
allocation  of  such  resources  was  problematic,  "it  was  difficult  to  secure  upper  management 
approval  for  people  to  spend  sufficient  time  on  RMARTS...  [W]e  tried  to  be  interdisciplinary 
early  on,  but  the  organization  wasn't  structured  in  a  way  that  let  us  be  helped.’^RMA  transi¬ 
tion  was  expedited  because  of  this  eventual  collaboration;  we  can  only  speculate  about  the 
benefits  of  constituting  the  interdisciplinary  group  even  earlier  on. 

The  mix  of  individual  skills  and  backgrounds  was  complemented  by  a  variety  of  transition 
mechanisms.  Technical  papers  and  tutorials,  quite  conventional  mechanisms,  were  used  by 
the  RMARTS  Project.  Early  on,  they  also  used  unconventional  mechanisms:  standards  work, 
resident  affiliates,  partnerships  with  compiler  vendors,  and  test  cases  worked  with  engineers 
in  external  organizations. 

If  transition  is  a  goal  early  in  the  development  of  a  technology,  concern  about  transition  suc¬ 
cess  pen/ades  the  development  effort.  RMARTS  personnel  had  early  exposure  to  SEI  transi¬ 
tion  concepts  and  goals.  We  have  seen  how  Qoodenough  and  Sha  incorporated  transition  into 
their  project  vision  through  the  RMARTS  stage  model.  While  the  need  for  a  vision  may  strike 


Personal  correspondence  with  John  Goodenough,  October  1993. 
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some  as  obvious,  many  technology  developers  are  unfamiliar  with  strategic  planning  or  third- 
generation  R  &  D  management  [Roussel,  Saad,  &  Erickson  1991]. 

Once  the  vision  is  developed,  a  transition  strategy  must  follow.  This  requires  an  understanding 
of  how  the  technology  being  developed  will  be  used.  In  1988  and  1989,  RMARTS  personnel 
worked  with  engineers  outside  the  SEI  and  learned  early  about  what  roadblocks  would  occur 
when  people  tried  to  adopt  RMA  to  build  “real”  systems.  Knowledge  of  these  obstacles  was 
subsequently  translated  into  questions  and  actions: 

•  How  would  compilers  have  to  change? 

•  Would  engineers  see  RMA  as  applicable  to  the  design  of  new  systems  and 
to  the  tuning  and  upgrading  of  old  systems? 

•  What  would  engineering  managers  need  to  know? 

Partnerships  were  critical.  When  an  organization  is  new,  small,  or  both,  there  is  great  advan¬ 
tage  in  teaming  with  a  larger  partner,  preferably  one  that  is  influential  and  has  deep  pockets. 
RMARTS  chose  such  a  partner  in  IBM,^  gaining  not  only  resources  such  as  a  resident  affiliate 
and  the  working  of  case  examples,  but  also  gaining  considerable  credibility.  In  addition  to  early 
co-development  partnerships,  distribution  partnerships  were  necessary:  RMARTS  may  have 
engaged  third-party  vendors  for  training  and  publication  fairly  late  in  the  technology  develop¬ 
ment  life  cycle.  In  hindsight,  project  members  observed  that  partnerships  with  trainers  and  tool 
vendors  might  have  been  worked  earlier  on  in  the  life  cycle.  We  cannot  say  to  what  extent  the 
transition  of  the  technology  would  have  been  accelerated  by  focusing  on  new  product  devel¬ 
opment  concurrently,  alongside  technical  development  and  extension.^^  An  increasing  num¬ 
ber  of  indicators  argue  in  favor  of  mutual  adaptation  of  technology  development  and 
implementation  [Leonard-Barton  1988a]. 

Finally,  developers  and  practitioners  must  continue  to  reflect  upon  their  transition  activities  and 
find  efficient  ways  to  capture  their  processes  so  that  lessons  can  be  shared  with  others 
through  experience  reports.  They  must  consider: 

•  What  aspects  of  the  process  are  important? 

•  How  best  can  they  be  described? 

•  To  whom  are  these  descriptions  relevant? 

•  How  early  in  the  maturation  of  a  technology  can  a  transition  process  be 
captured  and  still  predict  later  transition  approaches? 

•  How  can  we  anticipate  the  needs  of  the  change  agents  who  must  introduce 
the  technology  under  consideration? 

It  is  important  to  remember  that  IBM  had  a  longstanding  relationship  with  the  Advanced  Real-Time  Technology 
(ART)  Project  at  Carnegie  Mellon,  beginning  in  1982  and  continuing  until  the  present. 

This  is  a  problematic  issue.  Evidence  indicates  that  accelerating  technology  transition  requires  focusing  upon 
technology  development  and  product  development  concurrently.  However,  if  there  is  no  clear  existing  or  potential 
market,  it  is  difficult  to  engage  the  interest  of  product  developers  early  in  the  technology  life  cycle.  The  question 
remains:  what  would  make  product  developers  take  the  leap  of  faith  that  they  needed  to  invest  earlier  than  they 
did? 
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These  are  difficult  questions,  requiring  more  than  generic  answers.  Developers  and  practitio¬ 
ners  may  want  to  turn  to  case  study  research  as  well  as  others’  experience  reports  for  guid¬ 
ance  in  answering  these  questions. 

7.2  Implications  for  R  &  D  Managers  and  Funding  Agents 

Process-intensive  technologies  such  as  softwsu^e,  including  methods  for  designing,  developing 
and  testing  software  such  as  RMA,  require  implementation-intensive  transition  methods. 
While  there  is  evidence  that  software  technology  transition  can  be  more  systematic  [Leonard- 
Barton  1988a,  Leonard-Barton  1988b]  and  approaches  to  transition  can  be  replicated  [Acker¬ 
man  1983,  Bouldin  1989,  Grady  &  Caswell  1990],  the  problem  of  "discovering”  an  approach  in 
the  first  place  remains.  In  R  &  D,  during  the  construction  of  prototypes,  if  attention  is  given  to 
adoptability  and  ease  of  use  as  well  as  to  technical  correctness,  then  information  can  be  ob¬ 
tained  that  is  helpful  to  the  design  of  commercial-grade  products  or  techniques.  These  com¬ 
mercial  products  are  “whole”  [Moore  1991];  they  incorporate  the  secondary  products  and 
services  that  late  majority  adopters  need:  training  and  support,  courses,  document<^tion.  hand¬ 
books,  etc. 

Those  funding  technology  development  within  their  own  organizations,  or  in  external  organi¬ 
zations  such  as  universities,  expect  that  the  technology  being  developed  will  automatically  be 
used.  While  advice  for  technologists  and  managers  on  processes  for  selecting  an  optimal  mix 
of  R  &  0  projects  is  available— for  example,  [Roussel,  Saad,  &  Erickson  1991]— guidance  on 
how  to  attend  to  the  transfer  of  specific  types  of  technologies  that  these  projects  may  develop 
is  rare.  In  addition,  software  technologies  require  a  transition— no\  just  a  binary  transfer— pro¬ 
cess.  Funders  need  to  understand  what  development  and/or  transition  activities  they  are  fund¬ 
ing:  where  in  the  value  chain  or  maturation  life  cycle  the  technology  is,  what  arena  the 
technology  is  intended  for.  and  what  the  relative  cost  will  be.  (They  will  also  benefit  by  attend¬ 
ing  to  the  issues  for  developers  described  above.)  The  example  of  RMA  transition  does  not 
provide  all  the  answers,  but  the  level  of  detail  about  types  of  activities  over  a  significant  time 
period  may  stimulate  thinking  about  requirements  for  other  technologies.  These  requirements 
might  concern:  staffing,  facilities,  schedule,  and  financing. 

7.3  Implications  for  Transition  Research 

The  case  study  on  the  transition  of  RMA  represents  a  single  effort  to  understand  the  complex 
processes  of  software  technology  transition  auid  diffusion.  In  order  to  gain  a  full  understanding 
of  this  area,  researchers  must  consider  both  sides  of  the  technology  push/technology  pull 
equation  and  attend  to  the  full  range  of  transfer  conditions  from  R  &  D,  through  new  product 
development,  to  adoption  and  implementation  in  an  organizational  setting.  Such  an  under¬ 
standing  of  technology  transition  requires  crossing  boundaries  between  disciplinary  commu¬ 
nities  and  between  the  arenas  of  academia,  industry,  and  government.  The  latter  is  a  difficult 
task:  each  discipline  and  each  arena  speaks  about  and  investigates  technology  transfer  in  a 
different  way  [Fowler  &  Levine  1993,  Rogers  1983,  Tornatzky  &  Fleischer  1990]. 
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Additional  case  study  research  on  technology  transition  in  general  and  sofhware  technology 
transition  in  particular  is  essential.  Researchers  must  continue  to  explore  the  circumstances 
and  surrounding  conditions  for  transferring  software  tools,  techniques,  or  practices,  as  op¬ 
posed  to  other  kinds  of  technologies.  Such  distinctions  will  become  critical  as  more  and  more 
technology  is  layered— and  as  software  is  embedded  within  other  technologies.  Within  the 
software  transition  arena,  researchers  must  begin  to  focus  on  a  taxonomy  of  technology  types 
and  consider  distinctions  between  tools,  techniques,  integrated  toolsets,  and  larger  ill-defined 
process-based  technologies.  Because  of  its  nature,  software  raises  fundamental  questions 
about  process-  and  product-based  technology.  Understanding  these  relationships  will  help 
create  new  taxonomies  for  technology  beyond  current  manufacturing  operation  distinctions, 
such  as  customer  technology,  small  and  large  batch,  mass  production,  etc.  [Woodward  1965. 
Khandwalla  1974] 

Case  study  research  can  provide  the  basis  for  understanding  software  technology  transition 
issues  generally,  and  for  exploring  transition  with  respect  to  specific  technology  types  and  or¬ 
ganizational  settings.  How  does  the  transition  of  RMA  compare  to  that  of  a  CASE  tool?  A  soft¬ 
ware  development  environment?  A  human  behavior-intensive  technology  such  as  software 
inspections?  A  tool-based  technology  such  as  project  management  that  also  requires  human 
behavioral  changes  in  attention  to  detail?  A  grand-scale  composite  technology  such  as  soft¬ 
ware  process  improvement?  Finally,  how  does  the  transfer  of  these  technologies  vary  with  re¬ 
spect  to  the  nature  of  the  receiving  organization  or  environment? 

In  exploring  these  and  other  questions,  researchers  must  be  willing  to  innovate  and  to  borrow 
methods  of  inquiry  from  the  many  disciplines  that  shed  light  on  the  process  of  technology  tran¬ 
sition.  For  example,  the  study  of  RMA  raises  interesting  questions  about  the  types  of  people 
involved  and  the  communities  that  they  represented.  A  full  history  and  communication-network 
analysis  might  provide  many  clues  to  issues  of  diffusion  and  influence. 

Case  study  research  offers  us  a  way  to  understand,  in  depth,  how  software  technologies  can 
be  effectively  (or  not  effectively)  transitioned.  Such  studies  support  the  goals  of  technology  de¬ 
velopers,  their  managers  and  funding  sources,  and  researchers  alike.  They  reflect  and  honor 
the  complexity  of  real  transition  situations,  and  also,  as  their  number  increases,  provide  a  ba¬ 
sis  for  common  understanding  of  a  range  of  transition  experience  for  software  technologies. 
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Appendix  A  Rate  Monotonic  Anaiysis  1987-1993 


1987 

(Project  was  known  as  Real-Time  Scheduling  in  Ada~RTSi^ 


Technology 

Selected 

Kay  Umitatlona 
Addreeaed 

Value  and 

Tranaltlenabillty 

Demonatratad 

Self-Sustaining 

TransHlon 

Widespread 

Use 

(Is  it  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(to  it  easily  ieani^ 
and/or  bu%?) 

(What  support  to 
needed  for  sustained 
usage?) 

(Can  it  become 
common  practice?) 

Theory  of  rate  morwtonic  Theory  used  at  IBM 
scheduling  (RMS)  Manassas  tor  BSY-1 
obtained  from  CMU. 

network  (DSDB)  82-87 
and  on  R&D  project 
(RTCN)  86-87. 


fiM  deploys  HW/SW 
with  periodic-only  RMS. 


Conference  paper  on 
priority  osilmg  protocol. 

Work  with  compiler 
vendors  to  implement 
proposed  schMuling 
strategies. 

Real-time  systems 
exarnples  and  test  cases 
from  Navy,  IBM. 

Priority  inversion 
problem  in  Ada 
tasking  and  solution 
accepted  1st  Int'l 
Workshop  on  Real-Time 
Ada  This  leads  to 
Verdix  providing  Ada 
compiler  runtime  source 
code  for  experimentation. 


CMU/SEI-93-TR-29 


1988 

(Project  was  krK>wn  as  Real-Time  ScheduHng  in  Ada) 


promising 

Technology 

Selected 

Key  Limitations 

Addresasd 

Value  and 

TransHlonabillty 

Demonstrated 

Self-Sustaining 

Transition 

Widespread 

Use 

(Is  it  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(Is  it  easily  learned 
and/dr  bunt?) 

(What  support  is 
needed  tor  sustained 
usage?) 

(Can  it  become 
common  practice?) 

Reports  for  compiler 
vendors  about 
implementing  algorithms 
for  Ada  runtime  systems. 

Development  of  theory 
implementation 
validation  and 
performance  testa. 

Analysis  of  Real-Time 
EmbMded  Systems 
Testbed  (REST)  Project’s 
Inertial  Navigation  System 
for  refinement  of  theory. 


IBM  resident  slfiiiate 
arrives. 

Naval  Wea^ns  Center 
(NWC)  resneiTt 
affiliate  arrives. 

IBM  resident  affiliate 
in  collaboration  w/  senior 
IBM  engineers  modifies 
tutorial  materials  for 
IBM-internal  RMS  course. 

Generic  avionics  case 
study  developed  by  IBM 
and  NWC. 

Naval  Wei^ns  Center 
resident  affiliate 
developing  generic 
missile  case  study. 

R^esentation  of  the 
avionics  system 
implemented  using 
mMifled  Verdix  Ada 
compiler  to  determine  if 
predicted  performance 
can  be  obtained. 


Work  with  hardware 
bus  standards  groups 
(IEEE  FutursBus4-)  to 
aflow  affective  use  of 
prioritized  scheduling 
algorithms. 

Verdix  imptoments 
RMS-required  scheduling 
algorithms  in  its  Ada 
runtime  system. 

Other  compiler  vendors 
experimenting  with  the 
al^rithms. 

Work  with  Ada 
language  maintenance 
and  revision  efforts. 

IBM  experiment  with 
RTCN  at  IBM. 


One-day  tutorial 
prepared  to  give  to 
erwineers  at  SEI 
Affiliates  Symposium. 
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1989 

(Project  was  known  as  Real-Time  Schedulbig  in  Ada) 


nomiaatg 

Technology 

Selected 

Kay  Umltations 
Addreaaad 

Value  and 

TVanaMonabHIty 

DamonatrMad 

Self-Sustaining 

Transition 

Widespread 

Use 

(Is  it  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(Is  k  easdy  learned 
and/or  buNt?) 

(What  support  is 
needed  for  sustained 
usage?) 

(Can  1  become 
common  practice?) 

Analysis  of  REST  Projsct's 
Inertial  Navipation  System 
refinement  of 
y  completed  and 
modincatbns  made  to 
both  theory  and  INS 
system. 

Continued  interaction 
with  related  projects  in 
Carnegie  Mellon 
Univeraily’a  School  of 
Computer  Science  that 
focus  primarily  on 
scheduling  theory. 

An  Ada  program  that 
can  evaluate 
schedulabilify  algorithm 
is  developed 


Naval  Vt toons  Center 
resident  affwate 
continues  developing 
generic  missile  case  study 
and  consulting  on 
development  of  a  generic 
avionics  application. 

IBM  resident  affiliate 
consulting  on  application 
of  RMS  theory  to 
distriHited  systems. 

IBM  demonstrates  value 
of  RMA  intomaNy  by 
Wplyina  k  to  BSV-1 
Team  trainer. 

IBM  (at  IBM)  develops 
a  generic  avionics 
a^ication  in  cooperation 
with  NWC  to  demo  app¬ 
lication  of  theoim. 

IBM  loans  RTCN  to  SEI 
for  broader  experiment 


IBM  incorporates  RMS 
into  totemal  real-time 
systems  training  course, 
based  largely  on  SEI 
tutorial  materiaL 

Hardware  bus  standards 
groups  (IEEE  FutursBus+) 
continue  to  develop 
standards  that  allow 
effective  use  of 
prioritized  scheduling 
algorithms. 

Verdbc  continues 
implementing  RMS- 
required  scheduling 
algorithms  in  its  Ada 
mntims  system. 

Other  compiler  vendors 
continue  experimenting 
with  the  algorithms. 


One-day  tutorial  given 
to  ^ineers  at  SEI 
Affiliates  Symposium. 

One-day  tutorial  offered 
at  TriAaa89  breaks 
tutorial  attendance 
records  with  est.  220 
attendees  (usually 
about  40). 

Veidix  has  included 
changes  incorporating 
RMS  in  recent  compitor 
releases. 


IBM  deiTxmstrates  value 
of  RMA  by  applying  it  to 
BSY-2  Transmit  Group. 


Reprmntation  of  the 
avionics  system 
implemented  using 
modified  Verdix  compiler 
to  determine  if  predkrted 
performance  can  be 
obtained. 


Work  with  Navy’s  Next 
Generation  Cornputer 
Resources  (NGCR) 
Program  to  eiwourrm 
development  of  a  LAN 
that  supports  RMA 
principles,  issues  in  the 
transition  a  RMA  to  a 
distrbuted  system  are 
identified.  As  a  result  of 
this  effort,  a  serious 
priority  inversion  in  802.5 
IS  uncovered. 
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1990 

(Project  was  krK>wn  as  Rate  Morxitonic  Analyst  for  Real-Time  Systems-RMARTS) 

NOTE:  Focus  has  shiftsd  from  schaduling  algorithms  to  btoadar  applicatbn  of  RMS  thaory  to  dasign  ar>d  analysis  of  raal-tima 
systams.  Also,  nama  changa  is  dua  to  RMS  thaory  baooming  mora  widaly  known  and  thus  usafully  mantionad  in  tha  htia  of  tha 
projact.  Ada  ramains  a  prafarrad  madtanism  for  implamanting  RMS  thaory  but  is  not  tha  primary  focus.  And  bacausa  rata  monotonic 
analysis  is  now  tha  focus,  tha  acronym  is  RMA. 


Promising 

Tachnology 

Salactad 


(Is  it  potentially 
relevant?) 


Kay  Limitations 
Addressed 


(Is  it  potentially 
practical?) 


Value  and 

Transnionabllity 

Damonstratad 


(Is  it  easily  learned 
and/br  built?) 


Self-Sustaining 

Transition 


(What  support  is 
needed  for  sustained 
usage?) 


WMaspraad 

Use 


(Can  it  become 
common  practice?) 


Technical  report.  An 
I/O  Paradigm  for  Real- 
Time  Systems,  shows 
how  RMA  can  be  used  as 
a  factor  in  determining 
design  tradeoffs. 


Inertial  Navigation  System 
(INS)  anafysn 
demonstrates  applicability 
of  RMA. 

A  generic  avionics  case 
study  demonstrates  a  new 
design  for  such  systems 
based  on  RMA  principles 
(continues  1989  work). 

A  paper  (*A  Real-Time 
Locking  Protocol’) 
extending  the  rate 
monotomc  approach  to 
address  the  nckirtg 
problem  in  real-time 
database  applications 
accepted  by  IEEE 
Transactions  on 
Computers. 

BSY-1  trainer  study  shows 
how  RMA  can  lead  to 
dramatic  improvements 
in  an  existing  system. 


Benchmaik  tests  for 
Ada  compilers  to  check 
implementation  of  RMS 
al^rithms  are 
developed  and  beta 
tested. 

IBM  continues  to  offer 
RMA  in  internal  real¬ 
time  systems  training 
courses. 

SEI  technical  report. 
Implementing  Sporadic 
Servers  in  Ada,  is 
published, 

demonstrating  to  Ada 
programmers  and 
compiler  vendors  how 
the  sporadic  server 
algorithm  can  be 
supported  in  Ada. 

Rrst  in  a  series  of  SEI 
technical  reports  on  how 
RMA  addresses 
common  real-time 
programming  issues, 
AnArudysisof 
/nputOu^  Paradigms 
for  Read-Time  Systems, 
is  published. 

SEI  teaches  RMA  course 
to  various  BSY-2 
subcontractors  and  prime 
contractor.  Prime 
contractor  develops  its 
own  course  and  begins 
teaching  RMA  internally 
and  to  other 
subcontractors. 


RMA  tutorial/workshop 
offered  at  NASA 
Johnson  Space  Center 
and  at  Mcuonnell 
Douglas  (prime 
contractor  for  the 
space  station). 

NASA  adopts  RMA 
for  the  space  station 
data  mgmt  system. 
McDonnell  Douglas 
and  subcontractors 
such  as  IBM  and 
Honeywell  agree  to 
use  RMA  as  the 
baseline  approach 
for  designing  real¬ 
time  software.  NASA 
considers  requiring 
use  of  RMA  as 
baseline  approach  for 
all  real-time  software. 

RMARTS  works  with 
GE  on  various  subsys¬ 
tems  of  the  BSY-2 
mtem,  applyirig 
RMA  to  determine 
schedulability  of 
real-time  software 
designs  and  to 
recommend  and 
verity  (via  RMA) 
design  changes 
when  needed. 


European  Space 
Ageri^,  On-Board 
Data  Div.,  announces 
RMA  wiH  be  the 
baseline  methodology 
for  its  hard  real-time 
operating  sys.  project, 
rfhe  RkMRTS 
Project  had  no 
direct  contact  with 
ESA.) 
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1990  -2 


promising 

Technology 

Selected 

Key  Umltatlona 
Addressed 

Value  and 

Transftionabltlty 

Oemon^rated 

Self-Suetatoing 

Transition 

WIdeatMaad 

Use 

(Is  it  potentially 
relevant?) 

(Is  K  potentially 
practical? 

(Is  H  easily  learned 
and/br  built?) 

(What  support  is 
needed  for  sustamed 
usage?) 

(Can  it  become 
common  practice?) 

RMARTS  Pn^act  Introductoiy  article  on 

oontmues  to  irwure  RMA  and  Ada 

hardware  support  by  published  in  EEE 

seeing  that  RMA  is  used  Comput»r,  4/90. 
in  revising  FutureBuai- 

standard,  which  wiU  be  Two  papers,  ‘Maintain- 
implementad  by  all  major  ing  Global  Time  in  the 
hardware  vendors  and  is  uE  FutureBuef* 
one  of  the  Navy’s  Next  and  *Reai-Time 

Generation  Computer  ScheduKra  Support 

Resource  standards.  in  FutureBusf’*,  are 

accepted  for  publica- 
RMARTS  Project  tion  oy  the  Real-Time 

insures  that  standards  Systems  Journal  and 

for  operating  systems  IEEE  Miao,  respect- 

and  programming  ively.  These  pai^rs 

languages  allow  the  adoress  design 

use  of  RMA  by  working  issues  concerning 

with  POSIX  op.  systems  support  for  real-time 

standard  EEc  Pt 000.4,  syMam  development 

which  results  in  inclusion  bwed  on  RMS  theory 
of  some  basic  aspects  of  and  the  IEEE 
RMA.  FutureBuat-. 


Work  to  influence  Ada 
9X  standard  to 
encourage  use  of  RMA 
algorithms  is  initiated. 

Systems  Design  Manual 
for  IEEE  FutureBus+ 
contains  a  chapter  on  how 
to  use  the  FutureBus+- 
when  designing  real-time 
systems  based  on  RMA. 


Instructional  materials 
upgraded  and 
incorporated  into 
workshop  at  TriAda90 
and  the  IEEE  Real- 
Time  Symposium. 


Research  Institute  for 
Computing  and  Info. 
Systems  (RICIS)  adapts 
instructional  materials 
for  use  in  training  at 
NASA  and  its  contractors. 


RMA  theory  referenced  in 
part  in  real-time  computing 
courses  at  Univ.  of  Ma»s., 
U.  of  Illinois,  etc. 
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1991 

(Project  was  known  as  Rate  Monotonic  Analysis  for  Real-Ttme  Systems) 


Promising 

Technology 

Salactad 

Kay  Limitations 
Addrasaad 

Valuaand 

Transitlonabillty 

Oamonstratad 

Salf-Sustaining 

Transition 

WIdaaproad 

Usa 

(Is  it  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(is  it  easily  iearned 
and/or  built?) 

(What  support  is 
naadad  for  sustained 
usage?) 

(Can  it  baooma 
common  practica?) 

Work  with  the  CMU  Adv. 
Reai-Tima  Tach.  Projact 
to  axtand  tha  currant 
analytical  mathods  for 
assassing  schadulability 
continuas.  A  p^r, 

*Fixad  Priority  Schaduling 
of  Pariodic  Tasks  with 
Varyir^  Exacutiva 
Prioritias,’  coauthorad 
by  RMARTS,  is  acoaptad 
for  prasantation  at  tha 
lEtE  Raat-Tfma  Systams 
S^nryMsium  Daoambar 

Work  bagins  to  axtand 
RM  A  to  natworks  whara 
distributad  stations 
hava  to  oooparativaly 
schadula  tha  natwork 
with  inoomplata 
information.  (This  work 
to  ba  dona  by  a  CMU 
PhO  candidata  under  the 
suparvision  of  an 
RMARTS  Prcqact 
mambar.) 


Tachnical  nota  praparad 
dascribing  savaral 
algorithms  for  assassing 
tha  schadulability  of  a 
task  sat  with  arbitrary 
daadlinas. 

Oiract  support  to  BSY-2 
providad:  RMA  data 
shaats  davalopad  and 
usad  to  coHact  data  for 
rata  monotonic  analysis 
of  both  individual  arid 
intagratad  CSCIs;  rata 
monotonic  analysis  of 
individual  CSCn; 
tutorial  prasantad  to 
BSY-2  subcontractors; 
and  a  raport  on  how  to 
parform  RMA  on  BSY-2 
softwara  dasigns. 

Work  with  NGCR  Program 
to  anoouraga  davalopmant 
of  a  LAN  that  supports 
RMA  principtas.  End-to- 
and  schaduling  issuas 
ara  axaminad  and  IEEE 
802.6  natwork  standard 
is  raviawad  for 
applicability  to  tha 
raal-tima  domain. 


Transition  to  rasaarch 
community  for 
axtansion  of  RMA 
indudas  ooursas  and/or 
rasaarch  at  Taxas  A&M 
in  support  of  Spaca 
Station  Fraadom,  U.  Mass, 
Florida  Stata,  and  tha 
Univ.  of  Cotorado. 

Nanotak  announcas 
singla  board  computar 
products  for  FuturaBu&f, 
advartising  support  for 
RMA 

Tha  intarfaca  batwaan 
FuturaBuat-  and  othar 
LAN  standards  is 
axaminad. 

Continuing  support 
of  tha  transition 
of  FuturoBus^-  to  tha 
raal-tima  community, 
including  raviaw  of  u 
chipaat  dasigns,  work 
with  IBM  on  tha  raal- 
tima  chaptarof  tha 
fEEE  FutureBus* 

Smtern  Conjuration 
Manual 


An  ovarviaw  of  this 
chaptar,  *Raal-Tima 
Application  Using 
IEEE  FuturoBus-f,' 
is  aocaptad  by  IEEE 
AAcro for  publication. 

Prime  contractors  for 
PAVE  PACE,  a 
program  davaloping 
tha  naxt  ganaration 
architactura  for  AF 
avionics  systams,  ara 
ancouragad  to  usa 
RMA  Boaino  plans  to 
incorporata  RMA 

A  NASA  raport  that 
discussad  tha  rasults 
of  a  rata  monotonic 
analysis  of  tha  Space 
Staton  Data  Mgmt 
Systam  softwara  is 
raviawad. 

NASA  Spaca  Station 
studias  data  shaats 
davalopad  for  BSY-2. 


Work  with  tha  raal-tima 
POSIX  working  group 
continuas,  including 
incorporation  of 
proposals  regarding 
priority  inhantanca 
protocols  and 
procassor  allocation 
scope  for  threads  that 
were  ballotad. 
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1991-2 


Promising 

Technology 

Selected 

Key  Limitations 
Addressed 

Value  and 

TranMtlonabllHy 

Demonstrated 

Self-Sustaining 

Transition 

Widespread 

Use 

(Is  it  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(Is  it  easily  learned 
and/or  built?) 

(What  support  is 
needed  for  sustained 
usage?) 

(Can  it  become 
common  practice?) 

An  interim  solution  for  Ada  usage^rformance  NASA  downsizing 

users  who  want  to  begin  specs  are  developed  reduces  extent  of  use  of 

using  the  sporadto  server  to  ensure  programmers  RMA.  Project  members 

is  developed,  which  is  a  followirig  certain  convince  vendors  of 

modificatnn  of  the  restrictions  get  the  operating  systems  and 

sporadic  senrer  algorithm  benefit  of  performance  compilers  to  provide 

that  can  be  implemented  improvements  in  sporadic  server 

as  an  applicatton-level  generated  code  and  support  at  their  own 

Ada  task.  runtime  system  behavior,  expense  to  oompen- 

An  MOU  between  SEf  and  sate.  NASA  and  primes 
System  Designers,  a  agree  to  use  the 

compiler  vendor,  is  additional  options, 

signed  as  the  basis  Later  NASA  decides 

of  collaboration  on  this  to  use  RMA  for  all 

work.  Similar  MOUs  with  space  station 

other  compiler  vendors  software  when 

are  pursued.  applicable. 

Plans  are  formed  to  RMA  has  been 

develop  an  engineering  specified  for  use  with 
handbook  for  the  space  station 

application  of  rate  on-board  software  as 

monotone  analysis  to  the  means  for  schedul- 
real-time  systems.  ing  multiple  independ¬ 

ent  task  execution. 

An  intermediate  step  RMA  will  actually  be 
results  in  a  draft  report  built  into  the 

circulated  for  on-board  operating 

external  review,  *Rate  system,  and  is 

Monotonic  Analysis  direct  supported  by 

Adoption  Rationale,*  the  AuA  compiler 

which  answers  technical  in  use. 

and  managerial 

questions  about  RMA  NASA  Langley 

adoption.  schedules  RMA 

training. 

Sample  problems  and  a 
taxonomy  have  been  RMA  is  used  in  the 

devetopM  and  are  being  nuclear  partition  of 
reviewed.  BSY-2  with  RMARTS 

support. 

General  Dynamics  is 
applying  RMA 
during  development. 
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1991-3 


promising 

Technology 

Selected 

Kay  Limitations 
Addressed 

Value  end 

TransHlonsblllty 

Dsmonstrstsd 

Self-Sustaining 

Transition 

Widespread 

Use 

(Is  It  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(Is  it  easily  learned 
and/or  built?) 

(What  support  is 
needed  for  sustained 
usage?) 

(Can  it  become 
common  practice?) 

Data  ahaat  concapt, 
developed  for  BSY-2, 
will  be  ifworporated  in 
the  handbow. 

Pro^sals  for  Ada  9X 
revisions  are  reviewed, 
and  recommendations 
made. 

Woik  continues  to 
encourage  adoption  of 
the  sporadic  server  by 
Ada  vendors  and 
potential  users.  (The 
sporadic  server  is  Pie 
scheduling  mechanism 
introduced  by  RMA  tc 
provide  enhanced 
schedulability  and 
analyzability  of 
aperiodic  t«ms.) 

Students  in  the  SEI 
MSE  program  will  develop 
«  "not  to  support  RMA. 

A  commercially 
available  tool  set  is 
found  that  supports 
RMA  at  a  limitM  Iwel. 
Work  has  been  initiated 
to  contact  other  CASE 
tool  vendors  about 
support  for  RMA. 

Vendors  and 
contractors  in 
attendance  at  TriAda91 
and  the  IEEE  Real-Time 
Systems  Symposium 
indicate  RMA  adoption 
and  extension  through  its 
inclusion  in  their  products, 
trainir^,  and  by 
descri^ions  in  paper 
presentations. 


its  experience  in  a 
paper  reviewed  by 
RMARTS. 

Hughes  applies  RMA  to 
the  design  of  a  radar 
weaning  receiver. 

Boeing  Aerospace 
visits  SEI  to  determine 
schedulabHity  of 
software  redesign  of 
dual-processor 
SRA^II  using  RMA. 

Raytheon’s  plan  for  the 
Patriot  missile  ground 
control  software 
upgrade  is  reviewed 
with  respect  to  its  use 
of  Ada  and  the 
applicability  of  RMA.  A 
Raytheon  employee 
who  is  a  student  in  the 
SEI  MSE  program  will 
analyze  this  software 
usirig  RMA  as  part  of 
his  XKf^ndent  study. 

Software  performance 
tor  an  advanced  radar 
system  at  Atlantic 
Aerospace  is  reviewed 
by  RMARTS.  A  brief 
tutorial  is  also  provided. 
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1992 


Promising 

Technology 

Selected 

Key  Limitations 
Addressed 

Value  and 

Transit  tonabllKy 
Demonstrated 

Self-Sustaining 

Transition 

WIdesprsad 

Use 

(Is  it  potentially 
relevant?) 

(Is  it  potentially 
practical?) 

(Is  it  easily  learned 
and/or  buHt?) 

(What  support  is 
needed  for  sustained 
usage?) 

(Can  it  become 
common  practice?) 

Prototype  harKibook 
(v2)  restructured 
t>ased  on  test  results 
to  allow  contributions 
from  external  authors, 
and  distributed  to 
poterttial  contributors. 

Prototype  handbook 
(beta  version) 
extended  to  include 
realistic  case  studies, 
and  distributed  to  350 
reviewers. 

Vtfbrk  with  Naval  Warfare 
Center  at  China  Lake 
to  revise  RMA  tutorial 
to  create  baseline 
version  for  presentation 
at  WAd^. 

Work  with  Prof.  Ruth 
Ravenel  (U.  Colorado) 
to  develop  a  videotape- 
based  short  course, 
including  exercises 
and  course  notes,  on 
RMA. 

SEI  and  SPC  develop 
memorandum  of 
understanding  so  SPC 
can  inoorporate  RMA 
into  ADARTS  and  STC 
real-time  software 
development 
methodology. 

First  annual  RMA  Users 
Forum  (meeting  of 
vendors  and  users) 
held  ki  conjunction  with 
SEI  SympMium. 

SEI  works  with  U. 
Virginia  to  support  the 
prototyping  enort  for 
the  Ada  binding  to  the 
NGCR  lightweqht 
services  Intended  for 
use  in  the  real-time 
domain. 
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1993 


Promising 

Taehnology 

Selected 

Kay  Limitations 
Addrasaad 

Valua  and 

TransItionabHIty 

Damonatratad 

Salf-Sustalnlng 

Transition 

WMaspraad 

Use 

(Is  it  potentially 
relevant?} 

(Is  it  potentially 
practical?) 

(Is  it  aasity  laamad 
and/or  buM?) 

(What  support  is 
needed  for  sustainad 
usage?) 

(Can  k  become 
common  practice?) 

RMA  handbook  wrking 
eomplalad. 


Potantial  RMA  handbook 
publiahars  oontactad. 

Kluwar  Acadamic 
Publiahars  salaclad  to 
publish  handbook. 


Nagotiations  oontinua 
with  SPC  on  how  to 
oombina  RMA  with  SPC 
ADARTS  mathodology. 


Talos  sands  consultant 
for  training  at  SEI. 


2nd  RMA  Usars  Forum 
plannad. 


RMA  handbook 
ralaasad. 


SEI  works  with  Kluwar 
to  considar  a  hypartaxt 
varsion  of  tha  RMA 
handbook. 


RMAVidaoiorSEI 
Taehnology  Sarias 
tapad  at  0.  of  Colorado 
by  Prof.  Ruth  Ravanal. 

RMA  column  appaars  in 
EEE  C0n»9U(ar*Hot 
Topics”  column. 

RMA  'glossy*  praparad. 

Talos  offars  RMA 
public  coursas. 


Tri-Padfic  offars  RMA 
tutorial  at  Ada-Europe. 

Consumar  raal*tima 
markat  targatad  for 
RMA  with  nans  to 
attand  ano  participate 
in  1993  and  1994 
Embedded  Systems 
Confaranca. 
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